Mark Miller wrote:
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <bren...@mozilla.com
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=bren...@mozilla.com>>
wrote:
Mark S. Miller wrote:
As I understood Dave's clarification, 1JS is orthogonal to our
decisions about how many of the new features to make available in
sloppy mode.
No, Dave explicitly proposed that module be available in sloppy mode:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
"We can do better, and the way we can do it is with modules. We
can introduce module syntax in a backwards-compatible way, and use
them as the implicit opt-in for any new semantics [2]."
Sorry, I have only been skimming this thread and didn't realize that
Kevin had dropped "module". Yes, without even "module" being an
implicit strict opt-in, we have a different beast, and one that I
don't like.
Cool, good to get back to Dave's o.p.
I'm pretty happy with Kevin's compromise. Here it is again:
(1) No opt-in required for new syntax, except:
(2) No breaking changes to sloppy mode, and
(3) No grammar contortions (e.g. let) to support sloppy mode. And
(4) All new syntax forms with code bodies are implicit strict.
What do you say?
My preference order:
1)
1.a) To the extent clean and practical, new features are available
only in strict mode,
Just checking: is this because you want to promote "use strict"; usage?
1.b) Lexical f-i-b is available in sloppy mode as it is in ES6 strict,
since no browser will prohibit f-i-b syntax in sloppy mode. Better to
have the f-i-b sloppy semantics be aligned with the ES6 f-i-b strict
semantics.
Agreed, and this requires evangelization. We need an action plan.
1.c) modules (both inline and out) implicitly opt-in to strict mode.
Note Kevin had inline modules legal as new syntax only under strict mode
(via "use strict"; above in same unit, or else via next case), while
out-of-line module bodies would be strict by definition.
1.d) classes implicitly opt-in to strict mode.
1.e) nothing else causes an implicit strict mode opt-in.
2) Like #1 but without #1.d (which I think of as Andreas' position)
Sounds right, but let's let Andreas fend for himself :-P.
3) Like #1, but #1.e is replaced with
3.e) All code bodies within new function syntax is implicitly strict.
4) Like #3, but #1.a is replaced with
4.a) To the extent clean and practical, new features are available in
sloppy mode.
I take it this is essentially your position and Kevin's compromise
position?
Yes, I think so, provided "clean and practical" means no 'let' in sloppy
mode, per Kevin's item (3).
5) Where things stood at the end of the last TC39 meeting, where we
were violating the "clean" of #4.a to kludge things like "let",
non-duplicated-formals-sometimes, no-arguments-sometimes, weird
scoping for default argument expressions, etc, into sloppy mode.
Good to call this item (5) out. It needs more discussion. Whatever
micro-modes mean, if we make new syntax in sloppy mode affect semantics
of surrounding code, e.g., of the whole parameter list due to just one
formal using destructuring, then we indeed have a difference from your
1-4 including sub-items.
I still think such non-local effects could be worth it, but they are a
separate item from the others, especially your (4.a), the grand K-B
compromise ;-).
6) Like #2 but without #1.c. Is this essentially Kevin's
pre-compromise position?
Not quite, as noted above Kevin really meant "no new syntax outside of
strict code", so an inline module would have to nest directly in a "use
strict";-governed code body, or else nested directly in an out-of-line
module body. I.e., only out-of-line module bodies were implicityin (not
opted into, nothing optional about it :-P) strict mode.
Thanks for the detailed order of preferences. Could you say a bit more
about your rationale for this order?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
