Make comma at the end of line optional

Jeremy Martin jmar777 at gmail.com
Tue Sep 12 18:48:32 UTC 2017


Apologies, I was butchering the property getter syntax. With the correct
syntax, the backwards compatibility concern remains, however:

    const get = "foo";

    const obj = {
      get
      y() { return 2 }
    };

    console.log(obj.get);
    // current: `undefined`
    // under this proposal: `"foo"`

You can try it yourself here: https://es6console.com/j7hy49k4/



On Tue, Sep 12, 2017 at 2:36 PM, Алексей <agat00 at gmail.com> wrote:

> Am... no. Right now this example would just not work. For now this code is
> invalid.
>
> 2017-09-12 21:33 GMT+03:00 Jeremy Martin <jmar777 at gmail.com>:
>
>> *> The reason why we have a discussions about whether to rely on ASI or
>> insert them manually is because ASI has problems (return is one of them). *
>>
>> This seems to come from the perspective that ASI was a poorly specified
>> feature, as opposed to a recovery mechanism for poorly terminated
>> statements.
>>
>> That being said, even with ASI completely removed from the discussion,
>> your proposal has some significant barriers to overcome -- most notably the
>> lack of backwards compatibility.
>>
>> Examples have already been provided where your proposal would change the
>> semantics of *already *valid code. E.g.,
>>
>>   const get = "foo";
>>
>>   const obj = {
>>     get
>>     y: 2
>>   };
>>
>>   console.log(obj.get);
>>   // under current rules: `undefined`
>>   // under your new proposal: `"foo"`
>>
>> If you introduce new rules to resolve that ambiguity or to preserve
>> backwards compatibility, you've now created a situation similar to ASI,
>> where developers have to remember a list of exceptions before they elide a
>> comma.
>>
>> Even in the absence of backwards compatibility concerns, you need to
>> provide a persuasive argument that the cost-benefit ratio justifies the
>> effort, and judging from initial feedback, I think that will be an uphill
>> battle.
>>
>> On Tue, Sep 12, 2017 at 2:12 PM, Алексей <agat00 at gmail.com> wrote:
>>
>>> The reason why we have a discussions about whether to rely on ASI or
>>> insert them manually is because ASI has problems (return is one of them).
>>> And they can't be fixed because fixes are not backward compatible. Based on
>>> this experience it would be possible to determine the rules that would not
>>> have that gaps or their kind.
>>>
>>> 2017-09-12 20:32 GMT+03:00 Claude Pache <claude.pache at gmail.com>:
>>>
>>>>
>>>> > Le 12 sept. 2017 à 18:57, Алексей <agat00 at gmail.com> a écrit :
>>>> >
>>>> > Don't you think that line break is a strong punctuation by itself?
>>>>
>>>> It could have been. Unfortunately, in JS, it is not.
>>>>
>>>> Automatic semi-colon insertion (ASI) could be seen as an attempt to
>>>> have their cake and eat it too. Or, as a compromise between the two options
>>>> by making *some* line breaks significant (e.g., the one after `return`).
>>>>
>>>> But in general, line breaks are not significant enough to allow to
>>>> introduce ASI-like rules after the fact, that would work reliably enough.
>>>>
>>>> BTW, the title of the thread, “Make comma at the end of line optional”,
>>>> reveals a probable misunderstanding of the feature. In JS, semicolons are
>>>> not “optional”, they are “automatically inserted”. That makes a difference
>>>> when parsing:
>>>>
>>>> ```js
>>>> a = b
>>>> +c
>>>> ```
>>>>
>>>>
>>>> —Claude
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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>
>>
>>
>


-- 
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170912/0a870ddc/attachment-0001.html>


More information about the es-discuss mailing list