Moving String.prototype.substr to normative part of the spec

Brendan Eich brendan at
Sat Aug 4 13:34:38 PDT 2012

TC39 won't agree to all the trash in Annex B becoming 
normative-mandatory. Normative-optional is enough for browsers and other 
embeddings that want full interop. For the future, do we really want 
stinking Y2K-broken-by-design getYear, copied from Gosling's 
1995-or-older java.util.Date, to be mandated for all JS embeddings?

I do not. From time to time we have to prevent a fork of ECMA-262 into 
some "mobile" or "small embedded system" variant, which (a) has no room 
for such junk; (b) has no interop need. The web is not everything. I 
would venture that Node.js doesn't want getYear and other cruft from 
Annex B, either.


Mathias Bynens wrote:
> On 3 Aug 2012, at 20:34, David Bruant<bruant.d at>  wrote:
>> Le 03/08/2012 12:58, Allen Wirfs-Brock a écrit :
>>> substr is in Annex B, which in ES5.1 is an informative annex.  In ES6, the content of Annex B will be optional normative.  Required for web user agents, but optional for other hosts.
>> Ok. Is it planned to extend ES6-test262 scope to include tests for Annex B?
> FWIW, String#substr is mentioned in (as well as in the ES6 draft). I’ve written some tests too:
>> I'm wondering what's the downside of adding it in the normative part of the spec. It's in every browser, it's in Node.js, it's likely to be in MongoDB JS (I haven't tested, but it's based on SpiderMonkey 1.7, and soon V8), likely in all the mostly used JS platforms (which are often based on browser-included JS interpreters).
>> It's likely that platforms that support ES6 without substr will suffer from interoperability from libraries/modules that use it and rely on it and will be forced to add substr anyway.
> This is why it’s been included in Web ECMAScript/JavaScript, FWIW.
>> I guess I should ask the question: Are there known and used platforms that do not include substr? If the answer is no, then it probably should get in the spec for the sake of interoperability.
> I couldn’t agree more. IMHO, the whole Annex B should be made normative for all engines for interoperability/compatibility reasons.
> “Support Existing Content” is one of the [HTML] Design Principles (, and it would make sense to apply it to ECMAScript as well.
> Just my €0.02.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list