Rationalizing ASI (was: simple shorter function syntax)

Mark S. Miller erights at google.com
Mon Jul 26 14:11:58 PDT 2010


I'm proposing that the same opt-in that makes function call a restricted
production also turns off semicolon insertion, making that code into a
static syntax error. For those cases where the language can't reliably tell
what I mean, I don't want it to guess.

On Mon, Jul 26, 2010 at 2:02 PM, Waldemar Horwat <waldemar at google.com>wrote:

> Maciej Stachowiak wrote:
>
>> On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote:
>>
>>> Mark's restricted production idea is on target, if we think it's worth
>>> doing.
>>>
>>
>> At least in C or C++, I've seen code like this:
>>
>>
>> veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName
>>    (longArgument1, longArgument2, longArgument3, longArgument4,
>> longArgument5);
>>
>> If I understand correctly, Mark's proposal would make that a syntax error
>> in JavaScript. I'm not sure offhand if JavaScript programmers write in this
>> style, or would find the loss annoying. Of course, you could always write
>> this as a single very long line, or make sure that at least the open paren
>> is on the first line, but programmers can be picky about questions of style
>> like this.
>>
>
> If you made function invocation a restricted production then semicolon
> insertion would turn the above code into:
>
>
>
> veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName;
> (longArgument1, longArgument2, longArgument3, longArgument4,
> longArgument5);
>
>   Waldemar
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100726/cb89769f/attachment.html>


More information about the es-discuss mailing list