SE-0439: Allow trailing comma in comma-separated lists

Evolution Proposal Reviews
25

I follow along with many Swift Evolution proposals and am rather active in the community and don't comment very often, but I felt rather compelled to chime in on this with a different perspective.

  • What is your evaluation of the proposal?

A pretty strong -1. I'd like to take a few examples from the proposal itself of what wouldn't be allowed to illustrate why I don't consider this is a positive change.

enum E {
  case a, b, c, // ❌ Expected identifier after comma in enum 'case' declaration
}

protocol Foo {
  associatedtype T: P1, P2, // ❌ Expected type
}

(1,) // OK
(,) // ❌ expected value in tuple

Based on the examples above and the quote below, I believe the mental model for understanding when a trailing comma is allowed or not allowed is rather complex.

Trailing commas will be supported in comma-separated lists whenever there is a terminator clear enough that the parser can determine the end of the list. The terminator can be the symbols like ), ], >, { and :, a keyword like where or a pattern code like the body of a if, guard and while statement.

I'm not cherry-picking examples or trying to construct a straw-man argument, these selections were taken in succession directly from the proposal itself.

The mental model for when a trailing comma is allowed may be clear to a language designer, compiler engineer, or from a parser perspective, but as a developer who uses the Swift language and has been writing Swift every day for the last 10 years I find the rules and exceptions to be pretty confusing.

I have a hard time imagining a novice developer, perhaps you're a student or a junior developer, looking at Swift code and thinking these rules are consistent. Swift may be your first language or this is the first time you're writing Swift at a new job, and it's not a logical leap to imagine you coming away unsure of why trailing commas work in some places and don't in others.

My belief is that there is little benefit being gained here in a way that that necessitates that tradeoff. If this feature were something akin to a complex generics feature then I would understand the need for different syntax to represent a complex concept, but given this is going to be something every single developer encounters, I do not think it's a worthwhile change.

To make an argument by analogy, the ++ operator was removed from the language because it's not immediately obvious how it works to someone who hasn't written a lot of code. While I don't think we should make every decision based on that logic, I found that argument somewhat compelling for what Swift says it strives to be, and find this change to be a pretty strong 180 from that logic.

  • Is the problem being addressed significant enough to warrant a change to Swift?

I'm open to being convinced this is a problem worth solving, but I don't think so. I won't deny the fact that it will make prototyping easier, but I generally agree with some comments above which note that this change prioritizes writability over readability.

  • Does this proposal fit well with the feel and direction of Swift?

Ultimately the only people who can decide this are the core team because they determine what fits the feel and direction of Swift, but it's not something I would like in my platonic ideal of a Swift programming language.

For example I'm much less opposed to trailing commas in collection literals, a choice that was made in Swift 1.0. I don't find that choice to be consistent with the language's emphasis on directness over indirectness, but you could make an argument that arrays are unbounded in nature so it's ok there. (Like I said, I'm open-minded and not trying to be difficult.)

I generally think the solution to an exception is figuring out an abstraction that makes the exception more clear or more explicit, not expanding other surface areas of a problem to be open to exceptions.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

As far as I know I haven't used a language that supports this feature but perhaps I'm wrong. (Swift, Objective-C, Java, Go, Ruby)

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read through this proposal and then re-read it to make sure I had properly grasped everything before leaving a comment.

13 Likes