Make comma at the end of line optional

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


Thank you for good summary. If this discussion would appears in future than
your mail is a great link to starts from

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

> *> What am I missing?*
>
> Nothing with respect to function arguments, AFAICT.
>
> But to beat the dead-cognitive-overhead horse again, the rules around ACI
> (Automatic Comma Insertion) appear to require too many exceptions. We've
> already covered:
>
>    - ACI doesn't apply at all between variable declarations
>    - ACI has exceptions around getter/setter properties in object
>    literals.
>
> I hadn't thought of these before, but there's also:
>
>    - ACI would need exceptions in object and array literals following
>    yield in generator functions.
>    - ACI would need exceptions in object and array literals following
>    await in async functions.
>
> I would wager this isn't an exhaustive list yet, either.
>
> To be clear, these aren't exceptions in the grammar itself (the ASI-style
> "insert comma if next token would generate a syntax error" is sufficient to
> handle all of these cases), but they *are* exceptions that developers and
> tooling would need to hold onto, and IMHO, relegate the purported
> readability improvements.
>
> On Wed, Sep 13, 2017 at 1:55 PM, Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
>
>> `x` <whitespace> `[y]` would be invalid syntax, right?
>> So
>> ```js
>> x
>> [y]
>> ```
>> would automatically insert a comma in the case of a function call
>> arguments list, right?
>>
>> That's exactly what would be desired. What am I missing?
>>
>> On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>>> On 9/13/17 9:57 AM, Naveen Chawla wrote:
>>> > By this behaviour (a modification to the initial "complete statement
>>> > produces comma" version of this proposal), everything would work
>>> > perfectly, no?
>>>
>>> If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
>>> behavior that makes any code relying on this a hard-to-read footgun",
>>> then the answer might be "yes".  For pretty much any other definition of
>>> "perfectly", I'm fairly sure the answer is "no".
>>>
>>> > Great to hear those counter-examples as I don't know enough about ASI,
>>>
>>> Still in the context of ASI, here are some examples of why ASI is a bad
>>> idea:
>>>
>>> 1) What does this return?
>>>
>>>    function f() {
>>>      return
>>>      5;
>>>    }
>>>
>>> 2) What does this alert?
>>>
>>>    var str = "hello";
>>>    var x = str
>>>    [x].forEach(() => alert(x))
>>>
>>> Now back to automatic comma insertion... In your example:
>>>
>>>    function doStuff(
>>>        x
>>>        y
>>>        z
>>>    ){
>>>    }
>>>
>>> if someone changes doStuff to take an array as the second arg and you
>>> modify the call as:
>>>
>>>    function doStuff(
>>>        x
>>>        [y]
>>>        z
>>>    ){
>>>    }
>>>
>>> suddenly you need to insert a comma after the "x" to preserve the right
>>> semantics, no?  This is not terribly intuitive or obvious.  It gets even
>>> worse in a situation like this:
>>>
>>>    function doStuff(
>>>        x
>>>        /* The next argument is an array for good reasons that we
>>>           will now expound on in a long comment, etc, etc */
>>>        [y]
>>>    ){
>>>    }
>>>
>>> Quick, tell me without testing this or looking at the spec for a while
>>> whether this is a valid call to doStuff, with one argument, or a syntax
>>> error that would trigger comma insertion.
>>>
>>> But more generally, if you just use your favorite search engine on the
>>> phrase "automatic semicolon insertion", you will get a slew of articles
>>> explaining the pitfalls.
>>>
>>> -Boris
>>>
>>
>> _______________________________________________
>> 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/20170914/dcea3b4a/attachment.html>


More information about the es-discuss mailing list