Could you show me an example of a fictional EDSL that gets better with newline separated lists?
> On 18 May 2016, at 16:02, Matthew Johnson <[email protected]> wrote: > > > > Sent from my iPad > > On May 18, 2016, at 8:08 AM, David Hart via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> 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. > > The way I edit code this would not add any extra keystrokes. Select new > line, insert comma rather than select new line and press delete. > > This feature would be fantastic when making EDSLs in Swift. It would help > them come out much cleaner any time they include a comma separated list that > is likely to be formatted on individual lines. > > Big +1 from me. > > >> >>> On 18 May 2016, at 14:20, Patrick Smith <[email protected] >>> <mailto:[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 >>>> <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 >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
