[wwweston]

It does break fundamental uses of the language. Throwing on missing properties is a near-hostile change for most current JS developers.

The given justifications for doing this, though, seem to be all about performance rather than an attempt to evolve the language.

If that's true, I think it's possible the proposal has a naming problem.

Calling it "use strong" implies that this is about evolving the JS language so that devs are spending time writing more strongly-typed code.

Calling "use optimize" would make it a lot clearer that this is not an attempt to Java-ify JS, and this is more something you'd primarily invoke for performance-critical code paths.

[leichtgewicht]

I fail to see how it breaks anything? It is opt-in. Aside from that "use optimize" is indeed a better naming.

[pygy_]

It is supposed to be backwards compatible.

    "use strong"
    try {
        foo = bar[maybeMissing]
    } catch {
        // only runs in strong mode
    }

The above will take different code paths depending on whether your JS engine supports "strong" mode.

[tragic]

That's a good spot.

I suppose it's a lot easier to declare one's intention to create a backwards-compatible subset than to actually create one.

Hope the V8 people are open to revisions on the details at least.

[reissbaker]

This is true of strict mode as well, which shipped in ES5.

    "use strict";
    try {
      a = true;
    } catch(e) {
      // only runs in strict mode
    }

It's true of any mode switch that makes the language smaller. You shouldn't write non-strict (or non-strong) code if you opted into that mode, and catching those errors defeats the purpose of using it.

But it's not only true of mode switches...

    try {
      JSON.parse("{}");
    } catch(e) {
      // only runs in browsers that don't support JSON.parse
    }

    try {
      [ 1, 2, 3 ].forEach(function(x) { /* ... */ });
    } catch(e) {
      // only runs in browsers that don't support forEach
    }

Or even just:

    const x = 10;
    // only runs in browsers that support const

Any language change can cause differences between what executes in one browser vs. what executes in another. What strong mode guarantees is that if your code doesn't throw errors in strong mode, it won't throw errors in non-strong-mode (which is more than many changes guarantee!). Any other kinds of compatibility guarantees are impossible to make unless your changes are literally meaningless.

[pygy_]

Indeed (regarding your first point), my bad. I hadn't read the complete proposal, just the SaneScript slides, where that point was not fully developed. From TFA, emphasis is mine:

However, a mode directive has the significant advantage that any program +not hitting any of the strong mode restriction+ should run unchanged in a VM not recognising the directive, and no translation step should be required.

Your next two points are different: the standard library additions can be polyfilled and the syntax change is intentionally backwards incompatible.