On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich <bren...@mozilla.com> wrote:
> Kevin Smith wrote:
>>
>>
>> It does not even contain the word "strict". IIRC (and I asked
>> about this at the last TC39 meeting and got verbal confirmation),
>> the idea of module {...} implying strict mode was latent, or
>> intended. I'm not sure about out of line modules.
>>
>> At this point, best thing is to summon Dave.
>>
>>
>> Since any new code will likely be written as a module (even in the
>> near-term, transpiled back to ES5), this would be the ideal scenario.
>
>
> Which "this" do you mean? modules (in or out of line) implying strict mode
> can target ES5 strict, no problem.
>
>
>> But I'm trying to think through the implications while waiting.
>>
>
> One more thought from me, then I'll shut up for a bit:
>
> Mark wants no "micro-modes" but really (and I appreciate his candor) wants
> no sloppy mode extension if possible. I see things differently but I've
> started coming down on the side of more implicit strictness: module, class,
> function*, perhaps we should revisit arrows. (Allen has to spec something in
> the way of poisoned or absent .caller, etc. on arrow function objects.)
>
> IOW, I want more strict extensions too, but implicitly! Again, having to
> write "use strict"; itself makes for more sloppy code over time, but new
> syntax can be its own reward for the new semantics.
Geez I find this tempting. But I cannot agree. Code is read more often
than it is written, and ease of opting into strict mode isn't worth
the price of making it harder to tell which code is in strict mode. I
agree with Kevin's point #3. "function*" and arrow functions, being
functions, have function bodies. For "function" functions, they opt
into strict if they begin with "use strict". It would be confusing to
a reader of code for some functions to do this implicitly. It would
not be confusing for *readers* to not have "function*" or arrow
functions available in sloppy mode. When reading sloppy code, these
new function forms wouldn't appear without a "use strict" pragma, and
so wouldn't raise any new strictness questions for readers.
Class is an interesting case though, for three reasons.
1) Its body is not a function body, and so it would be yet more syntax
to enable a class to opt into strict mode explicitly.
2) It is a large-grain abstraction mechanism, much like modules, and
often used as the only module-like mechanism in many existing
programming languages. (Yes, JavaScript is a different language. But
we called it "class" to leverage some of that prior knowledge.)
3) It looks as foreign to old ES3 programmers as does module.
So I recommend no implicit opt-in, except for module (of course) and
possibly class. If class does not implicitly opt in, we need to extend
the class body syntax to accept a "use strict" pragma.
As for what function forms or heads require explicit opt-in, that
hangs on the micro-mode issue. If you're right that we would not make
things simpler if these were available only in strict mode, then I
agree with your conclusion. More later after I review where these
micro-modes ended up, especially the scoping issues on default
argument expressions. What's the best thing to read to understand the
current state of these? How well does the current draft spec reflect
the current agreements?
I do think "let" should only be available in strict mode, rather than
the syntactic crazy rules we started to invent at the last meeting.
In writing this list, I realize that the specific issue that set me
off, f-i-b, is a red herring. Because of ES3 practice, everyone will
continue to support f-i-b somehow in sloppy mode. If we can get
everyone to adopt the block-lexical semantics for sloppy that they
have in strict mode, that's simpler than maintaining the current de
facto crazy semantics for these in sloppy mode and having them have
block lexical semantics in strict code. So I'm on board with
evangelizing the problem web sites to fix their f-i-b code.
>
> So I'm not convinced your slippery slope argument should prevail.
>
> /be
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
