> 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).
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.
Functions are not all small and simple in real code. Sure, a quick check
> for arguments, eval, and |this| usage should be enough -- but now I'm not
> using the new ES6 syntax to solve the problem at hand, I'm off doing
> strict-mode conversion for Kevin.
>
Well, you should be! : )
> What's more, this will litter functions under maintenace and
> ES6-incremental upgrade with "use strict", and then one will have to go
> back later and do more sweeping stoop-labor, picking up the redundant "use
> strict"; clutter and commoning it at a higher level via a module or a
> single "use strict" in an outer function or global code.
>
Um - find and replace, dude. : )
> And if you're in a situation where you can't go strict, then you surely
>> aren't ready to depend on transcompilation.
>>
>
> That's obviously not true. CoffeeScript does not generate strict code yet!
I meant for legacy JS. CS is all "new code".
> In 10 years loading code via script tags will be an abandoned practice,
>> except for bootstrapping the module loader.
>>
>
> 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!
* 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).
* 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 : )
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)...
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.
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.
Mission f**cking accomplished.
; )
{ Kevin }
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
