I agree.
> On May 12, 2016, at 3:36 AM, Vladimir.S via swift-evolution > <[email protected]> wrote: > > Fully support your opinion. > > > PS: can they actually be removed EVERYWHERE instead?! > > Yes, I believe it will be much better to propose feature to allow line break > instead of comma, so we can have: > > let x = [10 > 20 > 30] > > let y = [1 : "one" > 2 : "two"] > > (from proposal): > > func padStringToLength( > sourceString: String > destinationCount: Int > paddingStyle: StringPaddingStyle = .Left > paddingCharacter: Character = " " > ) -> String { > /* ... */ > } > > padStringToLength( > sourceString: "source" > destinationCount: 4 > paddingStyle: .Right > paddingCharacter: "" > ) > > let tuple: ( > string: String > number: Int > ) = ( > string: "string" > number: 0 > ) > > ... <SomeT > SomeU > SomeV> ... > > This solves all the problems with diffs, makes code much clean and nice, no > additional noise. Why we need these commas instead of this solution? IMO this > will be real step forward. > > Is there such a proposal? (Or probably was discussed already?) > >> On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote: >> >> -1 - for ever >> >> >>> On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution >>>> <[email protected] <mailto:[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 >>>> >>>> Reviews are an important part of the Swift evolution process. All >>>> reviews should be sent to the swift-evolution mailing list at >>>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> or, if you would like to keep your feedback private, directly to the >>>> review manager. >>>> >>>> What goes into a review? >>>> >>>> The goal of the review process is to improve the proposal under review >>>> through constructive criticism and contribute to the direction of Swift. >>>> When writing your review, here are some questions you might want to >>>> answer in your review: >>>> >>>> * What is your evaluation of the proposal? >>>> * Is the problem being addressed significant enough to warrant a change >>>> to Swift? >>>> * Does this proposal fit well with the feel and direction of Swift? >>>> * If you have used other languages or libraries with a similar feature, >>>> how do you feel that this proposal compares to those? >>>> * How much effort did you put into your review? A glance, a quick >>>> reading, or an in-depth study? >>>> >>>> More information about the Swift evolution process is available at >>>> >>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>> >>>> Thank you, >>>> >>>> -Chris Lattner >>>> Review Manager >>> >>> +1 from me. We should be consistent in either accepting or rejecting >>> trailing commas everywhere we have comma-delimited syntax. I'm in favor >>> of accepting it, since it's popular in languages where it's supported to >>> enable a minimal-diff style, so that changes to code don't impact >>> neighboring lines for purely syntactic reasons. If you add an argument to >>> a function, without trailing comma support, a comma has to be added to >>> dirty the previous line: >>> >>> --- a.swift >>> +++ a.swift >>> foo( >>> x: 0, >>> - y: 1 >>> + y: 1, >>> + z: 2 >>> ) >>> >>> Trailing commas avoid this: >>> >>> --- a.swift >>> +++ a.swift >>> foo( >>> x: 0, >>> y: 1, >>> + z: 2, >>> ) >>> >>> >>> In languages that don't support trailing commas, many users resort to the >>> abomination of leading-comma style, strangely popular in Haskell and >>> related languages: >> >> I am not sure I understand where the “abomination” lies in using >> leading-comma style… but I will try to see it. >> >>> --- a.swift >>> +++ a.swift >>> foo( x: 0 >>> , y: 1 >>> + , z: 2 >>> ) >>> >>> I think the trailing-comma syntax jives much better with Swift style. >> >> >> If commas are to be construed as elegantly but meaninglessly dropped little >> crumbs, then one can see why it might not matter where they go, or how many >> there are, which as well as begging the question of allowing them at the >> end, should equally prompt the question of completely removing them >> altogether. And if having extras is just /great anticipation on future >> needs/, should we think about considering the following lines as all >> equivalent >> >> let v0 = (1, >> 2, >> 3) >> let v1 = (1, >> 2, >> 3, >> ) >> let v2 = (, // just in case I want to add something at the front >> later?! >> 1, >> 2, >> 3,) >> let v3 = (1, >> 2, >> , >> 3, >> ) // just in case I want to add something in the middle or >> front later >> let v4 = (1,, >> 2,, >> 3,,) // lets be really good programmer, in case it doubles in >> length >> >> >> Aside from the good-anticipation interpretation of trailing commas, there >> is also the /thinking-interuptus/ line of interpretation: >> >> this and >> that and >> >> standing for: now hold your breath, I am not done.. or maybe I lost my >> train of thoughts so I am actually done… who knows.. read the next line to >> figure that out. >> >> >> As I recall there is an ongoing debate about long string literal… Perhaps >> this line of thinking can help there too?!! Swift would become very unique >> and progressive with something like: >> >> let var = this is a long string literal” // notice my continuation quote >> at the end >> which I am continuing to the” // notice how I am letting people >> know that, like my parameter list, >> next line and perhaps even” // my string may not be quite >> finished yet >> to the next one and even” // … >> >> Like in the convenient case of a trailing comma in a parameter list, I >> added a last quote character so that I can add another string later, >> without having to resort to the /cliche/ notion of a leading quote. and >> like with trailing commas, it is just a placeholder because my string is >> really finished for now! >> >> >> Another convenient area where this reasoning could potentially be applied >> might be logical expressions!!! The ability to anticipate on future needs >> to change a logical expression might also be neat there by allowing >> expressions like: >> >> if (cond1 && >> cond2 &&) { >> } >> >> which floats a lot than the overly tight: >> >> if (cond1 >> && cond2) { >> } >> >> I think I’m convinced… it is such a powerful concept it should probably >> extend to the english language at large and >> >> Cheers >> LM/ >> [just in case, I hope everyone has seen the tongue-in-cheeks tone ;-) ] >> >> PS: can they actually be removed EVERYWHERE instead?! >> >> >>> >>> -Joe >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
