excluding features from sloppy mode
brendan at mozilla.com
Thu Dec 27 23:36:43 PST 2012
Mark S. Miller wrote:
> On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich<brendan at mozilla.com> wrote:
>> 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".
No, not only by that syntax. They also may be *opted-in* by their
outermost enclosing function that uses such a prologue directive.
That's what makes this less a readability win under your argument. To
find the governing "use strict"; in a large program or (real bugs bit
ES5 here) concatenation is not easy. One is not "reading" at that point,
one is grepping or searching in an editor that can match brackets if not
do deeper analysis.
> It would be confusing to
> a reader of code for some functions to do this implicitly.
An outer function having "use strict"; can implicitly do this to an
inner function, and rightly so, but at arbitrary distance in KLOCs or
So I don't see the argument against "implicit strict" as overriding.
> 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.
Again, we want ES6 features such as arrows and generators to be adopted,
whether authors can afford to adopt strict mode in enclosing functions
or top-level programs, or not. Do not multiply risks.
It's one thing to have arrows and generators be implicitly strict, and
get them working without early errors on load and without runtime errors
It's another to say that anyone who wants to use such good new features
must migrate the entire enclosing function or program to strict mode.
That may be a large top-level script, with legacy issues compounded by
> 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.
Right. I don't think we've considered this carefully in TC39 yet.
> 2) It is a large-grain abstraction mechanism, much like modules, and
> often used as the only module-like mechanism in many existing
> we called it "class" to leverage some of that prior knowledge.)
Won't quibble ;-).
> 3) It looks as foreign to old ES3 programmers as does module.
More positive: it looks like a unit of new and stricter code, so it
could be strict by fiat, implicitly.
> 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.
Good, happy to have support for class bodies implicitly strict!
> 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?
Allen's latest draft already covers a lot of the function head
new-syntax-is-its-own-opt-in (including-extra-strictish-checks ;-).
> 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.
We should discuss at the next meeting, with more homework to do before then.
> 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.
Evangelization costs, even with volunteer help. It's work. Need to
organize it a bit and take all the fun out, and make it matter. More
under separate cover.
More information about the es-discuss