[swift-evolution] SE-0084 spinoff: Newlines as item separators

[David Hart]

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 <matthew at anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 18, 2016, at 8:08 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <pgwsmith at gmail.com <mailto:pgwsmith at gmail.com>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/0ca4df52/attachment.html>