Make comma at the end of line optional

Alexander Jones alex at weej.com
Mon Sep 25 19:27:07 UTC 2017


IIFEs start with a (. Putting line breaks before certain expressions can
help improve clarity. Your mind is made up but I have to protest. ASI
*sucks*. And the extra cognitive overhead it causes is utterly pointless.
If you don’t want to type them, why not program your editor to actually
insert ; and a linebreak at the same time when you want to terminate a
statement?

Many problems arise from parsing ambiguities — when writing code authors
know exactly what they intend, why make future readers second guess?

On Fri, 15 Sep 2017 at 11:12, Reinis Ivanovs <dabas at untu.ms> wrote:

> The "some examples" of ASI problems might as well say "all", since there
> aren't more than the two listed cases worth mentioning, and even the
> `return` one is kind of contrived, because putting line breaks after
> `return` isn't usually a thing. It also doesn't follow that ASI would be a
> "bad idea"; remembering not to start lines with brackets or parens is easy
> (especially with a linter, which people should be using anyway), and the
> benefit is less visually noisy code and a bit less typing. The same can't
> be said for comma insertion, because commas aren't as noticable or often
> used as semicolons, and the syntax would have more 'gotchas' than with ASI,
> so it's just not worth it.
>
> On Wed, Sep 13, 2017 at 6:22 PM, 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
>>
>
> _______________________________________________
> 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/20170925/712bf473/attachment.html>


More information about the es-discuss mailing list