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 <[email protected]> wrote: > > >>> On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution >>> <[email protected]> wrote: >>> On May 10, 2016, at 2:53 PM, Chris Lattner <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
