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

Sean Heber sean at fifthace.com
Wed May 11 10:39:25 CDT 2016


I think that, to me, the ability to allow trailing commas is linked with the ability to arbitrarily reorder defaulted parameters. If we retain arbitrary reordering of defaults (which I like and have taken advantage of), then we should allow trailing commas as well. Both of these features together help make quick playground prototyping and experimentation easy and painless.

l8r
Sean


> On May 11, 2016, at 10:09 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> 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
> _______________________________________________
> 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