Mark S. Miller wrote:
On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich<bren...@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
other metrics.
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
under test.
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
concatenation.
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
programming languages. (Yes, JavaScript is a different language. But
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.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
