excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Sun Dec 30 11:30:25 PST 2012

Axel Rauschmayer wrote:
> I agree. To me it comes down to cognitive load. A good way of 
> measuring that is whether one can state a simple rule. For Andreas’ 
> approach, it would be:
> “If you want the new stuff, turn on strict mode or wrap a module 
> around it.”

That is different from what TC39 has been working on, which Allen has 
been editing.

Making a simple statement is an easily gamed contest. Here's mine:

"If you want the new stuff, just use it."

I win :-|. Granted, some problems remain (more below)!

A couple of more serious comments:

We don't realize a better spec by pushing all new syntax into strict 
code, because the grammar doesn't know about modes. The grammar covers 
everything -- new syntax and old. So the semantics have to do "if 
strict, throw" on new syntax.

If we go down this road, we will crud up all the new semantics for new 
syntax with strict checks to throw early errors when the new syntax is 
used in sloppy code.

So the spec will be messier and the teaching slogan will be longer than 
it could be without the "turn on strict mode of wrap a module around it" 
part, if we go down this road. Perhaps it's the best path, but I am far 
from convinced.

> - Pro 1JS: You can use new stuff everywhere.
> - Contra 1JS: You can’t use all of the new stuff. There are tricky 
> exceptions and rules.

Check me: I think the only exceptions that we have found are let and 
function-in-block. At the last TC39 meeting, we resolved to try 
reserving let contextually in sloppy code. Results not yet in on that 
front, so by the book, following our own process, we should get some 
more data.

Function-in-block is indeed a problem without evangelization. But Mark 
said he was game. I don't know how much Google, Microsoft, Apple, and 
Mozilla can do to evangelize f-i-b content owners (if any are still 
around and actively maintaining) to switch from non-ES6 to ES6 f-i-b 
semantics, but that is also something we could try.

If we get past these two, then we're in the winning "Pro 1JS" / "If you 
want the new stuff, just use it" scenario.

> Another thought: What will JavaScript code look like once 99% of 
> browsers in use support ES6? Will we have a language with coherent 
> semantics and a simple structure? That is: is there a way to drop some 
> of the trickiness, long term? And which of the approaches gets us there?

You're getting ahead of reality here. Consider that no static code mode 
can tame implicit conversions, which strict mode leaves intact apart 
from removing |this| wrapping of primitives. Implicit conversions happen 
on values that can flow anywhere, including references to objects in the 
heap. There's no static strict/sloppy partitioning.

Implicit conversions remain the biggest WTF source. To tame them I think 
we need to work on value objects and beyond. This is nowhere in sight 
for ES6.


More information about the es-discuss mailing list