SE-0084 spinoff: Newlines as item separators


(Tino) #1

[Due to popular demand :wink: 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


(Vladimir) #2

list of generic types:
func f<T,U,V>(t: T, u: U, v: V) {
聽聽..
}

路路路

On 17.05.2016 21:06, Tino Heth wrote:

- method parameters
- array and dictionary literals
- tuples
[anything else?]


(Vladimir) #3

+1 for this feature.
I don't see any problem with it, just like we all don't see any problem with optional semicolon for code lines.
But I don't know if it will be possible(not too hard) to implement.

路路路

On 17.05.2016 21:06, Tino Heth wrote:

[Due to popular demand :wink: 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


(David Hart) #4

-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@swift.org> wrote:

[Due to popular demand :wink: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #5

I don't like this idea so -1 from me.

Most languages allow that extra comma at the end of a list and sure that
eases reordering a list but making them optional at all lines may make the
code confusing to read and put an extra job at the compiler to decide
whether a line is a new item or continuation from the previous line. This
may even be simpler to implement than I think but the code may become more
prone to errors as I may forget an item spans across two or more lines and
thus harder to read. If the clarity of code is a premisse of Swift, I think
this change would go against it.

- Leonardo

路路路

On 17 May 2016 at 15:22, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 17.05.2016 21:06, Tino Heth wrote:

- method parameters
- array and dictionary literals
- tuples
[anything else?]

list of generic types:
func f<T,U,V>(t: T, u: U, v: V) {
..
}
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Owens II) #6

Agreed with all of these points.

I鈥檇 personally like to see the 鈥,鈥 disappear altogether, but not piece-wise like this.

-David

路路路

On May 18, 2016, at 1:28 AM, David Hart via swift-evolution <swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Due to popular demand :wink: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #7

This would mean that we have to disambiguate generic parameter lists from comparison operators across lines:

聽聽// Is this `a<b, c>(d)`, or `(a < b); (c > (d))` ?
聽聽a < b
聽聽c > (d)

Maybe our existing lookahead rule is still sufficiently unlikely to misparse it (since we require a < to be followed by the type grammar, then followed by a '>.' or '>(' to parse as a generic param list), but that's something that'd have to be explored.

-Joe

路路路

On May 17, 2016, at 11:22 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 17.05.2016 21:06, Tino Heth wrote:

- method parameters
- array and dictionary literals
- tuples
[anything else?]

list of generic types:
func f<T,U,V>(t: T, u: U, v: V) {
..
}


(Patrick Smith) #8

I don鈥檛 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@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Due to popular demand :wink: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #9

It would cumbersome to transform to newline-separated list to a comma-seperated list, because you鈥檇 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.

路路路

Sent from my iPad

On May 18, 2016, at 8:08 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 18 May 2016, at 14:20, Patrick Smith <pgwsmith@gmail.com> wrote:

I don鈥檛 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@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@swift.org> wrote:

[Due to popular demand :wink: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #10

It would cumbersome to transform to newline-separated list to a comma-seperated list, because you鈥檇 have to add a character on top of removing the newline.

路路路

On 18 May 2016, at 14:20, Patrick Smith <pgwsmith@gmail.com> wrote:

I don鈥檛 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Due to popular demand :wink: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #11

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@anandabits.com> wrote:

Sent from my iPad

On May 18, 2016, at 8:08 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It would cumbersome to transform to newline-separated list to a comma-seperated list, because you鈥檇 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@gmail.com <mailto:pgwsmith@gmail.com>> wrote:

I don鈥檛 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Due to popular demand :wink: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #12

Could you show me an example of a fictional EDSL that gets better with newline separated lists?

I鈥檒l do better than that. I鈥檒l show and example of a real EDSL I implemented in Ruby in the early days of iOS. It was used to generate very efficient streaming SAX-style XML parsers which parsed the data directly into model objects without building an intermediate DOM (validating the data in the process). The generated parsers were implemented in Objective-C with some use of C code in the implementation.

Here is a sample in Ruby:

object :attribute1, :class => :ObjectiveCClassName do
聽聽聽聽integer :id
聽聽聽聽string :description
聽聽聽聽bool :is_active, :property => :isActive
聽聽聽聽date :created_at, :property => :createdAt
聽聽聽聽array :items do
聽聽聽聽聽聽聽聽object :item, :class => :AnotherObjectiveCClass do
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽float :amount
聽聽聽聽聽聽聽聽end
聽聽聽聽end
end

The EDSL was used to build a data structure describing the expected schema and how it maps to the model objects. That schema was used to generate the parser.

You would probably do some things different in Swift but a relatively direct translation will suffice to demonstrate how removing commas is desirable. This example will assume Swift is also the target language.

Operators are used so that the structure of the EDSL follows the Ruby closer rather than nesting the array inside of the parameter list). Please ignore the specific operator 鈥渘ames". I just selected something arbitrary.

Here is what we would have in Swift with commas (I modified the EDSL slightly to make it more type-safe as it was intended to have only one child node for `array` to define the element type):

object (鈥渁ttribute1鈥, type: ASwiftType) ++++ [
聽聽聽聽integer (鈥渋d鈥),
聽聽聽聽string (鈥渄escription鈥),
聽聽聽聽bool (鈥渋s_active鈥, property: 鈥渋sActive鈥),
聽聽聽聽date (鈥渃reated_at鈥, property: 鈥渃reatedAt鈥),
聽聽聽聽array (鈥渋tems鈥) >>>> object (鈥渋tem鈥, type: AnotherSwiftType) ++++ [
聽聽聽聽聽聽聽聽float (鈥渁mount鈥)
聽聽聽聽]
]

And here without commas:

object (鈥渁ttribute1鈥, type: ASwiftType) ++++ [
聽聽聽聽integer (鈥渋d鈥)
聽聽聽聽string (鈥渄escription鈥)
聽聽聽聽bool (鈥渋s_active鈥, property: 鈥渋sActive鈥)
聽聽聽聽date (鈥渃reated_at鈥, property: 鈥渃reatedAt鈥)
聽聽聽聽array (鈥渋tems鈥) >>>> object (鈥渋tem鈥, type: AnotherSwiftType) ++++ [
聽聽聽聽聽聽聽聽float (鈥渁mount鈥)
聽聽聽聽]
]

The difference isn鈥檛 super significant, but IMO every bit of unnecessary / undesirable syntactic noise in an EDSL is a flaw. The less noise the language requires the better it is for creating EDSLs. You want to be able to approximate the syntax you might design from scratch relatively closely.

In this case, items in the list are essentially statements / declarations in the EDSL. You don鈥檛 want commas here for the same reason we appreciate the omission of semicolons as line terminators in Swift and other modern languages.

The obvious advantage of using Swift is that you can design the EDSL to have very strict types and reject anything invalid at compile time.

The Ruby still feels slightly cleaner to me because Ruby allows you to omit parentheses for expressions that only involve a single method call. Ruby also has symbols which are lighter syntactically than string literals. Both of these are also features that might be interesting to consider adding to Swift IMO. For the sake of argument (but without considering whether that would be practical in the Swift grammar, and whether Swift would borrow Ruby鈥檚 colon for symbols) here is what you might be able to do in Swift if we do get those features:

(object :attribute1, type: ASwiftType) ++++ [
聽聽聽聽integer :id
聽聽聽聽string :description
聽聽聽聽bool :is_active, property: :isActive
聽聽聽聽date :created_at, property: :createdAt
聽聽聽聽(array :items) >>>> (object item, type: AnotherSwiftType) ++++ [
聽聽聽聽聽聽聽聽float :amount
聽聽聽聽]
]

This roughly as good as the Ruby, a language which is praised for the flexibility it allows in designing EDSLs. Pretty cool! (Of course while I loved it in Ruby, I imagine there would be a lot of controversy if we do ever consider allowing simple expressions to omit parentheses in Swift)

路路路

On May 18, 2016, at 10:51 AM, David Hart <david@hartbit.com> wrote:

On 18 May 2016, at 16:02, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

Sent from my iPad

On May 18, 2016, at 8:08 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It would cumbersome to transform to newline-separated list to a comma-seperated list, because you鈥檇 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@gmail.com <mailto:pgwsmith@gmail.com>> wrote:

I don鈥檛 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Due to popular demand :wink: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution