[swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Ricardo Parada]

My apologies... I did not know that trailing commas were already legal. Thanks for pointing that out. Nevertheless I don't think I would have supported that. 

I also understand that the trailing comma may help a "git diff" look better and simpler. 

The trailing comma still bothers me though because it looks like somebody forgot to add something or as if something got deleted by mistake. 

I would support the trailing comma so that the language is consistent but I don't think I would personally use it. 

> On May 11, 2016, at 11:09 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>>> On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
>>> On May 10, 2016, at 2:53 PM, Chris Lattner <clattner at apple.com> wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:
>>> 
>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
>> 
>>> 	* What is your evaluation of the proposal?
>> 
>> -1
>> 
>> I don’t like the proposal.  I understand the flexibility it gives to rearranging elements but to someone reading the code it looks like an element was removed by mistake.
> 
> 
> This objection is coming up quite often and I don't really see the difference between trailing commas in collections (legal in Swift)
> 
> let listenerKeys: NSDictionary = [
>     AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
>     AVSampleRateKey: 44100.0,
>     AVNumberOfChannelsKey: 1,
>     AVEncoderAudioQualityKey: NSNumber(int: Int32(AVAudioQuality.Max.rawValue)),
> ]
> 
> And trailing commas in parameter lists (not yet allowed in Swift):
> 
> public convenience init(
>     _ w: CGFloat,
>     _ h: CGFloat,
>     position: CGPoint = .zero,
>     backgroundColor: UIColor = UIColor.whiteColor(),
>     translucency alpha: CGFloat = 1.0,
>     borderWidth: CGFloat = 0.0,
>     borderColor: UIColor = UIColor.blackColor(),
>     cornerRadius: CGFloat = 0.0, // this is currently illegal
>     ){
>     ...
> }
> 
> Neither example reads to me as if an element was removed by mistake. Both greatly enhance programming flexibility. Both allow the final comma to be omitted and/or the elements to be re-ordered.
> 
> To summarize the complaints to date:
> 
> * It make code read like errors
> * Arrays and dictionaries are different "things" than parameters and tuples; They are structurally different
> * Parameter lists should always be of fixed size at deployment time; Once a signature is fixed and consumed, it's difficult to change
> 
> To which I reply:
> 
> * Well structured code needn't read like an error. The examples above show an in-house style that allows final commas. Your in-house style may differ and a linter can catch these issues.
> * Both collections and signatures are syntactically similar in layout even if they are semantically different in use. In Swift, complex method signatures with defaulted arguments like the example shown are not uncommon. Do not limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
> * Parameter lists and function signatures, like collections, can evolve, especially when using defaulted parameters, even when they are consumed at multiple points.
> 
> -- E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/d6d32e46/attachment.html>