It would cumbersome to transform to newline-separated list to a comma-seperated list, because you’d have to add a character on top of removing the newline.
> On 18 May 2016, at 14:20, Patrick Smith <[email protected]> wrote: > > I don’t really see what the issue with having to reintroduce commas would be? > The losing track of where the items are separated? > > Maybe there could be an Xcode key shortcut to toggle commas off and on for > newline separated items, like the current toggler for comments. > >> On 18 May 2016, at 6:28 PM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> -1 I see one big downside. Contrary to statements, which rarely appear on >> the same line, other list elements are more frequently reformatted, from one >> line to multiple lines and back. For example, I'll try to find function >> declarations with too many arguments (formatted on multiple lines) and >> refactor them to reduce the number of arguments and reformat them on one >> line. This style refactoring would be made more difficult because it would >> force me to re-introduce commas if they had been removed. Summary: I'm >> against this proposal because element lists can be frequently reformatted >> from one to multiple lines. >> >> On 17 May 2016, at 20:06, Tino Heth via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> [Due to popular demand ;-) in the discussion of SE-0084: Allow trailing >>> commas in parameter lists and tuples] >>> >>> The option to skip semicolons for statements followed by a newline is only >>> a tiny convinience, yet it is one of the most favored differences to C (and >>> one of the most annoying things to remember when you have to switch from >>> Swift to do some coding in Objective-C). >>> While lists of statements don't need a special separator character anymore, >>> other lists still rely on commas to separate items: >>> - method parameters >>> - array and dictionary literals >>> - tuples >>> [anything else?] >>> >>> SE-0084 targets to make it easier to reorder list elements by allowing an >>> additional comma after the last element; afaics, the same can be achieved >>> by making all of those commas optional, as long as there is a newline to >>> separate the next item (without those newlines, SE-0084 makes less sense as >>> well). >>> >>> This change is not incompatible with SE-0084, but imho it doesn't make much >>> sense to combine those features (at least in actual source code). >>> >>> So, first question: >>> What are the downsides of this change? (question zero is "are there any >>> other places where comma-separeted lists could be turned into >>> newline-separated lists?"...) >>> >>> Tino >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> 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
