[swift-evolution] Allowing trailing commas in argument lists

Thu Mar 10 02:09:28 CST 2016

This is a linter's job. 

Sent from my iPad

> On 10 Mar 2016, at 05:28, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Most people are good about it but there is always one or two who take advantage of something like this, and if you allow it they will. I think it would drive me crazy to see this:
> 
>  let person = Person( id: json['id’], name: json['name’], picture: Im2age(picture), friends: friends,)
> 
> This would drive the anally retentive people crazy! I mean Swift was great that it got rid of the braces here:
> 
> if x == y {
> } else {
> }
> 
> so no more running the parenthesis right up against the if. But someone I know does this now: 
> 
> if x == y{
> }else{
> } 
> 
> Arrrgh!
> 
> Can we force the space before and after the paren? Without requiring uncrustify? :-) 
> 
> 
>>> On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On Mar 9, 2016, at 2:34 PM, Grant Paul <grp at fb.com> wrote:
>>> 
>>> Thanks for the feedback everyone! A few more notes to add to the proposal:
>>> 
>>> - Rust also supports trailing commas in argument lists and tuples.
>>> - Alternative proposals suggested by Haravikk:
>>>     1. Support trailing commas only in multi-line argument and tuple declarations. This is an interesting approach, and would codify good practice in the language. It might make the most sense for a lint-style tool. On the other hand, in Swift, the choice of whitespace character is usually not significant. Putting this rule in the language would change that for only a small benefit.
>>>     2. Allowing trailing commas except when it could cause ambiguity; for example, with type inference, overloading, or default parameters. This seems like the most complete way to prevent mistakes, but it also seems like it might be difficult to implement if the allowed syntax changed based on the type checker. Would have to defer to people with more experience in the Swift compiler if this is feasible.
>>> 
>>> 
>>> Nisse — 
>>> 
>>> Echoing what Radek said, the JavaScript “comma first” style comes directly from a *lack* of support for trailing commas (in Internet Explorer specifically). That style appears to have been first suggested here: https://gist.github.com/isaacs/357981#gistcomment-397 — part of the rationale was "a final trailing comma will cause errors in MSIE”.
>>> 
>>> 
>>> Patrick and Ted —
>>> 
>>> Do you also see the same issue with incomplete thoughts when writing arrays or dictionaries, where Swift does currently support trailing commas? I think that case would be more likely than in argument lists: an incomplete argument list would fail to compile in most cases from an incorrect number of parameters, but an incomplete dictionary or array would necessarily still compile.
>> 
>> Absolutely.
>> 
>> I work on a geographically diverse team, which demands an interrupt-driven environment. Dealing with phone calls, emails, and IMs must take priority to maintain communication between team members. Sometimes those interrupts deal with code. Thus, if I'm coding a call site or an array/dictionary initialization site when an interrupt comes in, it is likely that I don't switch back to the context, leaving some incomplete code. I'm sure if I put my head to it, I could think of other places allowing trailing commands are going to hurt me more than help me. 
>> 
>>> 
>>> It could be a reasonable proposal to disallow trailing commas in all places, albeit one I would disagree with.
>>> 
>>> 
>>> Grant
>>> 
>>> 
>>>> On Mar 9, 2016, at 10:55, Patrick Gili <gili.patrick.r at gili-labs.com> wrote:
>>>> 
>>>> I have to agree with Ted. When I leave a "trailing comma", it's almost always because I constructing a call and didn't finish, for whatever reason. Thankfully, the compiler is nice enough to tell me when I committed this error.
>>>> 
>>>> Cheers,
>>>> -Patrick
>>>> 
>>>>> On Mar 9, 2016, at 9:44 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> Hi Paul
>>>>> 
>>>>> I don’t think that is a good idea because:
>>>>> 
>>>>> as in most human languages writing,
>>>>> the comma tells us,
>>>>> that more is following,
>>>>> ?
>>>>> ?
>>>>> .. oops. hey, no more text?   
>>>>> 
>>>>> So, to me your examples are incomplete statements,
>>>>> leading to mistakes when editing, me assuming that I
>>>>> didn’t finish typing the statement, when I started
>>>>> editing the source say, three months later.
>>>>> or, doing maintenance and having to fast-read through
>>>>> many old source files.
>>>>> 
>>>>> Is it really so hard to press the DEL key to remove
>>>>> the trailing comma?
>>>>> 
>>>>> Greetings,
>>>>> TedvG ,
>>>>> 
>>>>> 
>>>>> 
>>>>> (sorry no more text here :0)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Right now, Swift argument lists are not permitted to contain trailing commas. To make multi-line calls easier, we propose allowing trailing commas in argument (and tuple) syntax:
>>>>>> 
>>>>>> let person = Person(
>>>>>>    id: json['id'],
>>>>>>    name: json['name'],
>>>>>>    picture: Im2age(picture),
>>>>>>    friends: friends,
>>>>>> )
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=TiMad4REPS_rpOXRZiQytQ&m=5hE4Yb04I38N2u3hF1YNWi2rnd6td7WW3_sIMgH1UHU&s=QncXBAO3MI-M5GEJ-wFM9qPqCReaGIzogre9d5EubAE&e=
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/2c2e2e52/attachment.html>