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> 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> 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> 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
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
