I'm new too, but don't think that's exactly how things get proposed here :)

Spec changes don't start with solutions - they start with existing problems
you're trying to solve. For example. In ES6 I might do

```js
var res = ({
   "hello" : () => 12, /* no fallback */
   "world" : () =>  323, /* no fallback */
    ...
})[ myWord]
```

Or just an if, or other things. The cost of adding a keyword into the
language is big (you're breaking any code that uses that keyword as an
identifier which is a lot).

My suggestion is that you make a static analysis tool that warns people
about switch fallthrough and then advocate it. Tools like jshint/jslint
will warn you about it, using such tools can (and should IMO) be a part of
your build and release process.

Thanks,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140209/0ca5caa9/attachment.html>

I'm new too, but don't think that's exactly how things get proposed here :)

Spec changes don't start with solutions - they start with existing problems
you're trying to solve. For example. In ES6 I might do

```js
var res = ({
   "hello" : () => 12, /* no fallback */
   "world" : () =>  323, /* no fallback */
    ...
})[ myWord]
```

Or just an if, or other things. The cost of adding a keyword into the
language is big (you're breaking any code that uses that keyword as an
identifier which is a lot).

My suggestion is that you make a static analysis tool that warns people
about switch fallthrough and then advocate it. Tools like jshint/jslint
will warn you about it, using such tools can (and should IMO) be a part of
your build and release process.