I don't think a new mode is a good idea.
On Sat, Jul 22, 2017 at 10:36 PM, Alexander Craggs <
alexan...@debenclipper.com> wrote:
> 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> 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
