[swift-evolution] Allowing trailing commas in argument lists

Radosław Pietruszewski radexpl at gmail.com
Thu Mar 10 10:33:34 CST 2016 

> On 10 Mar 2016, at 16:59, Paul Ossenbruggen <possen at gmail.com> wrote:
> 
> Swift already enforces some formatting rules, for example:
> 
> x==y or x == y is legal
> 
>  but
> 
>  x ==y or x== y is not. 
> 
> This kind of sloppiness not allowed. You have to pick one, spaces or no spaces not a mixture. I don’t think Swift should be an enabler of sloppiness. 

AFAIK, It’s not allowed because it creates a potential parsing ambiguity, not because Swift wants to police your style.

> 
> To radek’s comment that linters are there for this, this means that I have to run it, and then we lose the main suggested advantage of the trailing comma which is that we don’t have two diff lines because I would be sure to make the linter remove the extra comma. Having that extra comma just looks wrong, just as it look wrong for me end an English sentence with a comma, 
> 
> As others have said, it is more likely an indication that it was an incomplete thought or mistake. 

Just as skipping “self.” looks wrong and sloppy to some people. But it’s useful enough that it’s better to allow it and let people who dislike it enforce their own rules with a linter.

Again, being able to write:

SomeStruct(
    foo: …,
    bar: …,
    baz: …,
)

is simply useful. You can add remove, add, and reorder parameters without worrying about commas. We have this in the array syntax already, and I seriously doubt anyone has ever been confused by it.

> 
> 
> 
> 
>> On Mar 10, 2016, at 4:34 AM, ted van gaalen <tedvgiosdev at gmail.com <mailto:tedvgiosdev at gmail.com>> wrote:
>> 
>> Oh no, hurry!! switch of your screens!! 
>> Hide under your desks!! 
>> The SourcePolice-- has arrived!!! :o)
>> 
>> Imho people should be free to format and style their source in any way
>> they like -apart from company and team enforced standards when 
>> working for or with them, of course.
>> For example, You might have noticed on this forum, e.g. that I always 
>> put brackets on a new line,  because I find it much easier to read. 
>> 
>> (not doing so, I personally consider this as a traditional bad habit, 
>> taken over from C and C++,  being useful only in long gone days of limited 
>> screen estate, when printing out sources was often the only way to have a 
>> good impression. Or in digital medieval times, It saved a lot of weight (literaly) 
>> when I still had to edit with punched cards as source carrier, as each card 
>> could only contain 1 line.)
>> 
>> Xcode respects largely personal preferences and e.g. in Eclipse, Netbeans 
>> one can set one's own formatting preferences. However, for instance, the 
>> Dart-language-people, in al their unlimited wisdom, found it necessary to 
>> enforce a formatting dictatorship. You can't customize source formatting.  
>> What they enforce is in their vision the only perfect way. Silly. 
>> 
>> So, it you want to write code like ( fasten seatbelts, please)
>> 
>>    if a>b {c = b}else{c=a;swap(a,b);arrgh(arrghument)} // etc.
>> 
>> That's ok with me..  as long as I don't have to maintain your code.
>> The only (formatting and other) standards one should, or rather, must 
>> conform to are those necessary when working in a team, or e.g.
>> when contributing source entities to Swift open source.
>> 
>> And where is the end? you could even take this 1984 style dictatorship 
>> much further, e.g. by not allowing identifier names to be < 3 characters etc. 
>> (or removing certain unstylish source elements, but that's another matter, is it not?)
>> 
>> I'd say, it is rather a matter of commonSense++.
>> 
>> I've worked long ago in a Cobol team where it was not allowed to 
>> start an if block with a "not" like so (in Swift):
>>   if ( ! someFunc(value)
>>   { 
>>        spanishInquisition()
>>   }
>> we then had to write it like so:
>>   if someFunc(value)
>>   {
>>   }
>>   else
>>   { 
>>        spanishInquisition()
>>   }
>> Because that was the company's way of doing things,
>> stemming from the endless wisdom of the local gods,
>> 
>> ?
>> (sorry CommaConfusion (wow, that's a really cool name for a band!))
>> 
>> people that worked there for twenty years or so,
>> without noticing that there is a world outside their fences...
>> 
>> but perhaps it also has to do with the fact that,
>> at least for building my own apps++, I've metamorphosed
>> into being an Indie Developer, and some aspects of
>> that are very cool, like not loosing 50% of my time
>> (although having plenty of it) for team coordination.
>> The luxury of doing things, at least in this domain, 
>> the way I prefer.
>> 
>> TedvG.
>> 
>> 
>> 
>> On 10 Mar 2016, at 09:09, Radek Pietruszewski <radexpl at gmail.com <mailto:radexpl at gmail.com>> wrote:
>> 
>>> 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 <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Mar 9, 2016, at 2:34 PM, Grant Paul <grp at fb.com <mailto: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 <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 <mailto: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 <mailto: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 <mailto: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= <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 <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/4d40f394/attachment.html>

More information about the swift-evolution mailing list