If something requires so much special casing just to work, it's
fundamentally broken and best avoided altogether. Sloppy mode is
fundamentally broken. `eval` is fundamentally broken. TC39 people have
already generally accepted this as truth. Could we avoid adding more broken
features to the language? Just saying.
(TL;DR: Just let this thread die.)
On Wed, Sep 13, 2017, 15:08 Jeremy Martin <jmar...@gmail.com> wrote:
> *> 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.c...@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 <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
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
> _______________________________________________
> 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
