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