Stricter "use strict"
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript. They try to follow the "1JS" rule, that is there is only one language. Among other things, this makes writing parsers and interpreters easier. I think this all started at 1 (you don't need to read everything, but it gives an idea).
Strict mode was necessary to fix big flaws of the language that needed to be fixed and couldn't be without a mode, but that's as far as it went. Based on the examples you gave, it seems you haven't pointed at major language flaws that justify a new mode. More on that inline.
Le 16/04/2013 10:28, Francisco Ferreira a ?crit :
Stuff that pops my mind that
"use strict"doesn't cover and that couldbe useful is:
"use stricter";
- Enforces the use of
;at the end of a line of code
Be careful, this can be a sensitive topic for some people and may end up with flames :-) On that topic, I highly recommend Brendan Eich's article 2 which among other things summarizes a drama that animated the JS community.
- Either force the usage of '===' instead of '==' or make '==' moretype safe.
You might be interested in restrict mode 3
- Makes
map[undefined]break or throw a warning
By "map", i assume you're referring to a regular object and not an ES6 map. What do you mean by "break" and "throw a warning"? Do you want a runtime error to be thrown or this error to be caught by devtools?
As a developer, one thing you can do is at least build a tool (like
restrict mode) and add git/mercurial/svn per-commit hook to enforce that
your 2 first points are enforced. This way, when you and your team write
JavaScript, you can be guaranteed that semicolons are in and that no one
uses ==. I don't fully understand your 3rd point so I'm not sure a tool
can catch that, but my point is that by building tools yourself, you can
enforce the sublanguage of your choice in your projects.
Just to clarify about the map[undefined] example. Yes I'm talking about the
regular object var foo = {}, I know this is a minor detail, but I assume
that whenever undefined is set as a key (both for insertion and
retrieval). It's most likely because something wrong happened. I can't
imagine a logic that depends on setting foo[undefined] = 'something'. And
the developer should be warned about it either with a thrown runtime error
or with a console warning.
Thanks for the references, that pretty much clarifies what I had in mind.
On 16 April 2013 11:12, David Bruant <bruant.d at gmail.com> wrote:
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript. They try to follow the "1JS" rule, that is there is only one language. Among other things, this makes writing parsers and interpreters easier.
It doesn't. Quite the opposite, in fact. However, it is supposed to make the programmers' lives easier.
Le 16/04/2013 11:54, Andreas Rossberg a écrit :
On 16 April 2013 11:12, David Bruant <bruant.d at gmail.com> wrote:
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript. They try to follow the "1JS" rule, that is there is only one language. Among other things, this makes writing parsers and interpreters easier. It doesn't. Quite the opposite, in fact.
Oh, sorry about the misinformation, then :-s Could you elaborate, please? I'm interesting in understanding how more modes is easier from an implementor perspective. Or/and why less mode makes things harder.
Thanks,
On 16 April 2013 12:15, David Bruant <bruant.d at gmail.com> wrote:
Le 16/04/2013 11:54, Andreas Rossberg a écrit :
On 16 April 2013 11:12, David Bruant <bruant.d at gmail.com> wrote:
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript. They try to follow the "1JS" rule, that is there is only one language. Among other things, this makes writing parsers and interpreters easier.
It doesn't. Quite the opposite, in fact.
Oh, sorry about the misinformation, then :-s Could you elaborate, please? I'm interesting in understanding how more modes is easier from an implementor perspective. Or/and why less mode makes things harder.
Every new feature may potentially need to do slightly different things in different modes. The semantic matrix of supporting all features in all modes can then easily be more complex than just adding the new features to a subset of the modes. It depends how difficult the interaction between new features and legacy modes is on average. For example, certain ES6 features interact rather badly with non-strict mode and/or web reality (e.g., block-scoped functions). Not supporting them there would have simplified matters.
Thanks Andreas that was a great input.
But in that case the original question still stands, are more modes planed?
Although the solution with the "restricter pluggin" would work, it would also be cool to have a native "more strict" solution. Given your answer, "Not supporting them there would have simplified matters.", then it would force the language to evolve. i.e.: "If you want to use feature X you must write your code as required by mode Y". Note that as "use strict", any new mode would have to be backwards compatible in terms of syntax, the only difference would be that the call to "new feature X" would just output a warning to the console, do nothing, and continue.
Alternative with multiple modes maybe we could provide the developers with configurable options where they can explicitly activate/deactivate certain restriction features.
On 16 April 2013 13:45, Francisco Ferreira <francisco.m.s.ferreira at gmail.com> wrote:
But in that case the original question still stands, are more modes planed?
No, I don't think anybody wants more modes. At least not as official part of the language. But of course, that does not prevent linters, VMs, or debug/development tools from implementing additional compile or run time warnings. V8 already has some simple ones, e.g. to log out-of-bounds typed-array accesses.
/Andreas
Andreas Rossberg wrote:
No, I don't think anybody wants more modes. At least not as official part of the language.
Right, "no more developer-facing opt-in versioning schemes or modes in ECMA-262" is the TC39 mood, if not mode ;-). I doubt it will change.
Are there plans for a stricter
"use strict"? I think everyone can agree that having"use strict"is already a big improvement compared with not having it. But can't it be improved?Stuff that pops my mind that
"use strict"doesn't cover and that could be useful is:"use stricter";;at the end of a line of code===instead of==or make==more type safe.map[undefined]break or throw a warningp.s.: I've been following es-discuss for a month or two, this is the first time posting here so I hope I'm not covering something massively discussed already.