- What is your evaluation of the proposal?
Strong -1 for me too for three seperate reasons:
Ambiguity
This proposal introduces several ambiguities which can have a severe impact when writing Swift and more importantly, when reading it, especially in environments with no access to any kind of tooling (code review online for example).
Static Member Ambiguity
The proposal mentions this ambiguity. I've written a concrete example which I think is fairly believable (users do tend to define properties on enums for avoiding to use the pattern matching syntax) which parses and type-checks successfully but differently depending on the presence of the comma.
enum FooBar {
case foo
case bar
var foo: FooBar? {
if case .foo = self {
return self
} else {
return nil
}
}
var bar: FooBar? {
if case .bar = self {
return self
} else {
return nil
}
}
}
let a = [
FooBar.foo
.bar // enum case or property?
]
Closure Ambiguity
The proposal does not mention this ambiguity and I've not seen anybody mention it. Again, the following piece of code parses and type-checks successfully but differently depending on the presence of the comma.
func doSomething(_ action: (Any) -> Void) -> Void {
action("something")
}
let b = [
doSomething
{ _ in print("next") } // closure or trailing closure?
]
Consequences of Ambiguity
As a consequence of the previous ambiguities, the proposal mentions that the comma can sometimes be necesary to disambiguate. I personally think that the noise from one off commas are worse than consisteny commas:
// While no commas is nice
foo(
foo
baz
.bar
foobar
)
// I find one-off commas
foo(
foo
baz,
.bar
foobar
)
// worse than consistent commas
foo(
foo,
baz,
.bar,
foobar
)
Editing Inconveniences
While I agree that code is more often read than written, I think that this change can cause some minor editing annoyances. I often find myself rewriting expression lists from single-line to multi-line when they grow too long to nicely fit on one line, and from multi-line to single-line when they shrink enough to be more readable on one line. If one chooses to take advantage of this proposal to ommit trailing commas in multi-line expression lists, switching back and forth between single and multi-line can be more annoying than currently because of having to add/remove commas.
- Is the problem being addressed significant enough to warrant a change to Swift?
This proposal is interesting for EDSLs. But in my opinion, the small benefit it brings is not worth the list of disadvantages presented above.
- Does this proposal fit well with the feel and direction of Swift?
No opinion here.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I don't know of a language with a similar feature. It would be interesting to research if there exists one and how that feature works in that language.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A good read.
and read the proposal.