Make comma at the end of line optional

Алексей agat00 at gmail.com
Wed Sep 13 15:04:38 UTC 2017


Yes, this is the reason why I didn't mention the variable declaration in
initial proposal - it is 100% valid syntax in current implementation (and
100% relative error in strict mode)

But the design problems of ASI are incomparable with a special case of get
and set

2017-09-13 17:55 GMT+03:00 Jeremy Martin <jmar777 at gmail.com>:

> Quick side note regarding multiple variable declarations: both versions of
> this proposal (OP's newline-based proposal and the ASI-inspired version)
> result in code breakage:
>
> ```
> const
>    x = 5
>    y = 6
>    z = 7
> ```
>
> Under existing ASI rules, this is currently equivalent to:
>
> ```
> const x = 5;
> // y and z are global
> y = 6;
> z = 7;
> ```
>
> If we use newline based comma insertion (or give ASI-style comma insertion
> precedence over semicolon insertion), then this proposal would result in
> the following equivalent:
>
> ```
> const
>   x = 5,
>   // y and z are now lexically scoped constants
>   y = 6,
>   z = 7;
> ```
>
> Unless I'm missing something, both of those scenarios definitely preclude
> multiple variable declarations from this proposal.
>
> That being said, the ASI-inspired semantics seems like it could have more
> legs in other contexts, although I would personally argue that too little
> is offered in exchange for the cognitive overhead of a new rule with
> ASI-style exceptions attached to it (i.e.., "comma before newlines, except
> after get, and set, variable declarations, ...").
>
>
> On Wed, Sep 13, 2017 at 9:57 AM, Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
>
>> I'm not really familiar with ASI but they key factor mentioned in this
>> discussion is this (by Claude Pache):
>>
>> *A implicit semicolon is not added when a declaration would be complete,
>> but when the next token would produce a syntax error. *
>>
>> By this behaviour (a modification to the initial "complete statement
>> produces comma" version of this proposal), everything would work perfectly,
>> no?
>>
>> The multi-line get would not produce a comma, and hence the scheme is
>> backwards compatible, right?
>>
>> Please provide a counter-example if I have missed something.
>>
>> As for the benefit, the time savings in not having to debug accidentally
>> omitted commas and not having to add them in the first place are, I think,
>> an improvement. And of course those who want to continue using commas
>> everywhere, can:
>>
>> ```js
>> function doStuff(
>>     x
>>     y
>>     z
>> ){
>> }
>> ```
>>
>> ```
>> const
>>    x = 5
>>    y = 6
>>    z = 7
>> ```
>>
>> Great to hear those counter-examples as I don't know enough about ASI,
>> and the related subject, to picture the pitfalls (sorry for my ignorance on
>> this). Also it would be good for reference on this proposal...
>>
>> On Wed, 13 Sep 2017 at 18:40 Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>>> On 9/13/17 9:05 AM, Naveen Chawla wrote:
>>> > Can someone remind me of the problem doing it this way, if any?
>>>
>>> You mean apart from all the existing footguns ASI has?
>>>
>>> -Boris
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853 <(661)%20312-3853>
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170913/da0dc92c/attachment-0001.html>


More information about the es-discuss mailing list