[swift-evolution] Allowing trailing commas in argument lists

Paul Ossenbruggen possen at gmail.com
Thu Mar 10 21:27:26 CST 2016


I see them as harmless in arrays and enums because they grow and expand depending on the needs, but I think in argument lists, it means that is supposed to match with the signature, as soon as you add a comma then you are not really matching the signature there is another parameter that is empty,. If it is a  variadic function it makes even more confusing. Do we pass an empty value there? 

If we allow it we are going to have dangling commas in every function. I think that we should do our best to make Swift code look good, this does not really do that, it makes it look like someone forgot something or they were lazy. Javascript, PHP and other languages encourage sloppy coding. I don’t want to do that too. 

Someone made the argument that the Swift formatting commission is coming. I do think that having reasonable standards would help the overall readability and understanding in the code. We just spent a lot of time coming up with standards for naming APIs, I think the same should be done here to make it so that Swift code is generally readable and we don’t need to have obfuscation contests. 

Things to consider:
• Requiring spaces after commas. 
• A space before and after braces in control statements.
• Space after colon. 

Things will be unlikely to codify:
• forcing to put the brace at end of the line or on next line although Swift seems to have a defacto standard of putting at end of line. As much as I would like a standard here.

Already enforced:
* space before or after a comparison. like x == y. 

Also, perhaps the IDE could make following these standards automatic. So if you rearrange arguments, it would automatically add or remove the trailing comma but we don’t inflict reading that extra comma at the end of the argument list. It may not bother you but I guarantee others will be bothered by it. I am not talking about reformatting like old IDEs used to do either where every character was formatted, more like what happens when you do code completion. 

- Paul




> On Mar 10, 2016, at 3:23 PM, Rainer Brockerhoff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 3/10/16 17:27, Erica Sadun via swift-evolution wrote:
>>>>> On 10 Mar 2016, at 17:28, Radosław Pietruszewski <radexpl at gmail.com <mailto:radexpl-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>> wrote:
>>>>> 
>>>>> Trailing comma is not nonsensical, there is a specific purpose in allowing it (unlike your examples), and there’s precedent in Swift already.
>>>>> 
>> 
>> Trailing commas enable easier re-ordering of arguments, simplify growing or compacting argument lists, and do no harm.
>> 
>> Their use in arrays and dictionaries are conventional enough that experienced programmers will not be surprised by their
>> presence. No one will force their use and one's internal style guide (and linters) can direct whether any individual group
>> adopts or ignores the addition.
> 
> +1!
> 
> I became aware that trailing commas were now allowed in (Obj)C
> relatively recently and use them exclusively now in lists of enums,
> array and dictionary constants, and so forth.
> 
> Of course with a preprocessor they allow conditionally inserting
> elements without any conditional gimcrackery or the hack of inserting a
> final dummy element without a trailing comma.
> 
> Even so, optional trailing commas will no doubt be useful in Swift too.
> I think specifically of commenting out (or uncommenting) elements during
> debugging or exploratory programming.
> 
> 
> 
>> For those of us who prefer trailing commas, it will be both a convenience and an asset. For those against, there's no harm
>> done. I find it unlikely that trailing commas will naturally lead to any unsafe code or produce a net negative effect on the
>> language or the code-base it supports.
> 
> Excellent argument, too.
> 
> -- 
> Rainer Brockerhoff  <rainer at brockerhoff.net>
> Belo Horizonte, Brazil
> "In the affairs of others even fools are wise
> In their own business even sages err."
> http://brockerhoff.net/blog/
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list