Can't do that. Web sites rely on it.
"use stricter"?
1. Modes are bad for implementations (this feeling was strong from V8 folks such as Erik Corry, but the new crew in Munich may not feel the same way), due to code branching burdens in testing and optimizing while keeping the complexity down.
2. Worse, what you propose would fork the language to double the testing burden for web devs (apart from engine implentors, item 1), since older browsers would ignore the useless expression statement.
This already happened with ES5 "use strict", and created real world bugs (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=631043, there are more like this).
Developers do not test all the combinations. Notice how a tower of M modes implemented via these string-expression-statement prologue directives can make a 2^M-fold testing burden.
How can real pragma syntax work on the Web? Only by using a compiler such as Traceur or Babel, otherwise old browsers would choke on the `use types;` unquoted directive.
Note how this can still complicate VMs, but it doesn't fork the test load for web developers. And if the type system results in early errors, plus better optimization with unforked runtime semantics, then the only burden on VM implementors is in the parser and type checker.
We shall see how this experiment works, but in no way is it like `"use stricter";`.
> We shall see how this experiment works, but in no way is it like `"use stricter";`.
I might be misunderstanding your comment, but stupidcar's link (http://www.2ality.com/2015/02/soundscript.html) mentions `"use stricter;"` and `"use stricter+types;"` as mode flags, although it also contains a big disclaimer ("The final version of SoundScript may look and work completely different").
Has the syntax been changed since February? If so, I'm interested in reading about it (but my Google-fu is failing); got a link?
http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirect...
There are two ideas:
1. A `"use stricter";` (originally "use sanity" :-/) prologue directive that would not change runtime semantics for code that passed all of static checks, (control flow dependent) dynamic exception-throwing tests, and runtime restrictions on object behavior.
2. A "SoundScript" mode, perhaps enabled by a `use types;` opt-in, or expressed some other way (per module?), that enables gradual type checking based on optional annotations inspired by TypeScript, but with TS-incompatible differences.
Mode 1 might fly with TC39, because it does not fork semantics for code that passes all checks. But for real-world code, there will be divergence when run on old vs. new browsers, so I expect push-back in TC39 on this mode being expressed by a useless string expression statement.
Mode 2 cannot be enabled by a fake-string-expression-statement "prologue directive".