Kevin Smith wrote:
First, maybe the "1JS" term is a bit confusing and should be retired.
You're not in marketing, are you :-P.
(I wasn't for most of my career but ended up doing it 50-50 with talent
scouting/coaching/nagging. Sucks to be me! :-P)
1JS is too short and tweet-sweet to die.
I think a few simple rules are in order:
1) No opt-in required for new syntax, except:
2) No breaking changes for sloppy mode.
3) No implicit opt-in to strict mode.
Everyone agrees on rule #1. Rule #2 implies no "let" declarations in
sloppy mode, and no breaking block function semantics in sloppy mode.
(Are there others?)
Completion reform, a runtime semantic change. See
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform.
Rule #3 is probably the most controversial, but I think it's important.
Indeed, it goes against Dave's original proposal that module opt into
strict mode, which avoids some problems with sloppy mode in modules,
e.g. implicitly created globals by assignment to free names.
If we have implicit opt-in to strict mode via new syntax:
- Figuring out what code is sloppy and what code is strict is going to
end up the domain of language lawyers. A casual user should not have
to know when a particular syntactic feature was added in order to know
what are the runtime semantics for that code. All a casual user
should have to know is to put "use strict' at the top of the file.
This is a slippery-slope argument. _Contra_ some controversialists, I do
not find such arguments fallacious on their face. Lots of bad things
happened by "boiling the frog" (in real life I'm told the frog jumps out
in time).
On the other hand, Dave proposed 1JS with *only* module implicitly
opting its bodoy into strict mode. That is a line we can probably hold.
I suggest (I'm not sure, need to think more) that adding class (and
perhaps even function*) to the set of "heads" whose bodies are
implicitly strict wouldn't slide too far down-slope, but going from 1 to
>1 is the big bad change. So let's say that only 'module' implies
strict code in its body.
- Taking advantage of new syntax (perhaps in the head of a function)
will trigger completely unrelated semantic changes. This feels messy.
That's right, and we (TC39, and es-discuss too IIRC) agreed that new
function head syntax, whatever it might do in the way of banning
duplicate formal parameters, does not imply strict mode for the
function's body.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
