Huh, in which case I will! What are your thoughts on the non-error message part of this proposal? On 23/07/2017 06:34:48, Jordan Harband <ljh...@gmail.com> wrote: Error messages 1) are unspecified, 2) change all the time, 3) vary by language, 4) vary across browser/engine implementations. There is zero reason that any error message couldn't be changed, and in fact, many browsers do improve them over time.
I'd say before believing it can't be done, try filing tickets on Chromium, Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a more favorable response than you think. On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <alexan...@debenclipper.com [mailto:alexan...@debenclipper.com]> wrote: (Apologies for the double email Jordan, I accidentally replied to just you, not es-discuss as well. I'm new to this whole mailing list thing.) Apologies, that was a bad example. I was more considering "use strict" to be breaking in the sense that some things that worked without it would no longer work with it. That doesn't match the current scenario at all. In terms of other threads giving reasons why no new modes were likely to be introduced, most that I could find appeared to fail in the sense of the content they provided, installing rules that were better found in a linter, as opposed to a parsing mode. Do you have any points on why the idea itself is unlikely to be implemented as opposed to the content? I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string. We would have to add some new detection feature for this newer flavour to allow better messages. But error messages were the lowest suggestion for this new functionality, and probably another bad example. Just consider the hundreds of previously rejected proposals that were very promising but couldn't be used because of breaking backwards compatability. On 23/07/2017 05:50:31, Jordan Harband <ljh...@gmail.com [mailto:ljh...@gmail.com]> wrote: Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string. There's lots of other threads on why no new modes are likely to ever be introduced. There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker. On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <alexan...@debenclipper.com [mailto:alexan...@debenclipper.com]> wrote: One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago. It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years. We *did* introduce some breaking changes though, using the "use strict" header at the top of files. Would it not make sense to introduce new breaking changes under a similar header for each change we suggest? For example, "use es7" could allow people to say they are using the latest features. Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`: ```js < function u() { let x = await "hi" } > Uncaught SyntaxError: Unexpected string // Now... < "use es7"; < function u() { let x = await "hi" } > Uncaught SomeError: "await" keyword used outside of async function ``` _______________________________________________ es-discuss mailing list es-discuss@mozilla.org [mailto:es-discuss@mozilla.org] https://mail.mozilla.org/listinfo/es-discuss [https://mail.mozilla.org/listinfo/es-discuss]
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
