Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in "either it's an
identifier, or it isn't" default. If we can do it for 'module',
why not for 'let'?
Easy: "module" is still a first class identifier, but with your
proposed contortions, "let" is not (under sloppy mode, of course).
No, that's not correct. We have sloppy-mode code using 'let' as an
identifier (whatever "first class" means) today. We don't want to break it.
The only place 'let' is contextually reserved in the quasi-consensus
from the last TC39 meeting is at the start of a statement, when followed
by an identifier, '{', or '['.
Similarly, 'module' is used and usable as an identifier, but not in
malformed syntax that ES6 proposes to define: 'module' [no
LineTerminator here] ModuleName ... at the start of a statement.
Personally, yes. Only modules loaded by the module loader are
implicitly strict.
Now I'm confused. What about module M {...} (inline body)? What
does "the module loader" mean, the system loader?
Inline modules only in strict mode, in accordance with the rule. Only
out-of-line modules are implicitly strict.
Any use-case-based rationale?
Thanks for clarifying the primacy of "the rule". It was not clear, and
it does not match what Dave proposed that Mark reconfirmed as "1JS".
Although Dave left some wiggle room in his first post, I want to say
that my attempts to make all new body-forms strict don't fit under the
consensus "1JS" name and I'm not trying to usurp it. Your proposal
should be called "2JS" since to get the new stuff, you have to "use strict".
I will bet you real (beer) money you're wrong.
Alright - I'll take you up on that. If in 2022 anyone is using script
tags for anything more than bootstrapping a module loader, I'll buy
you a New Year's Eve beer!
Deal.
* It's an eyesore, which I think is a non-trivial objection.
Yes, but it's not required in out-of-line modules. Which will
predominate quickly in new code (my prediction, yes).
I don't think so in the browser. Concatentors will be required to
minimize requests, which will make modules inline again.
* It is easy to leave out and hard to find when checking whether
code in the middle of a function nest is strict.
Yes, it is easy to leave out, at least until you want to use an ES6
feature. Then you get spanked : )
Yeah, that's the thing I find turns off people at the "social BS" level.
The Strunk&White-ian prescriptivism rings false and the kids start
sassing off the gray-hairs. Not good for the Shire :-P.
I'm going to stop there.
Brendan, I feel like I'm in a compromising mood this evening. I can't
really tell whether it's because your arguments have merit or because
of argument by sheer exhaustion (as a previous computational theory
professor of mine once said)...
We can wait till next year :-P and re-check. I'm not trying to bully
anyone, just be a vigorous advocate (but not devil's advocate).
In any case, here's my compromise:
(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.
Wow, I like!
Still some friction for 'let' that will retard 'var' replacement but
it's survivable in my muddy palantir.
This might seem like a complete giveaway of my previous position.
However, if the above four rules are adhered to, ES6 sloppy mode will
be an incomplete, incomprehensible jumble of features and modes. An
insane language, to which the only sane response will be to hang it
all and just go all-strict.
If you say so. I suggest sloppy mode will be less used with (4) strict
bodies than in the case you formerly advocated, due to the friction
caused by rounding up adoption cost to use-strict conversion of
surrounding code body.
Mission f**cking accomplished.
Let's take a breather. I am not out to force anyone into a bitter
concession.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
