[Pitch] Allow trailing comma in tuples, arguments and if/guard/while conditions

Yet another tangent about single-element tuples

Mirror would disagree with this:

print(Mirror(reflecting: ()).displayStyle!) // tuple

I don't understand why having this special rule "single-element tuple is the tuple's element". It makes the language and its usage more complicated. What was the driving force of that unfortunate (IMHO) decision? Lack of proper syntax to make single element tuple? We could have come up with something that works like (x:1) or (1,) suggested above or or even Tuple(1) (naturally allowing Tuple(1,2) form and (1,2) being a shortcut), etc.

These two statements can't be both true:

  • "(1) is already a single-element tuple, which is the same thing as the single element"
  • "access the individual element values in a tuple using index numbers starting at zero (e.g. tuple.0, etc)"
2 Likes

There's quite a bit of background in other threads on the forum if you search for single element tuple. I don't think it needs to be rehashed again in this thread, which is only tangentially related.

4 Likes

You are right. Let's continue the single-element tuple discussion in another thread and focus on trailing commas themselves here.

1 Like

What I experience from the parser is prolong compilation that feels like shift-shift-shift-shift-crap-pop-pop-pop-pop-pop-pop-shift-shift-shift-shift-shift-pop-pop-shift-shift etc. It seems that the parser not having statement termination keeps trying to create a very long token chain and just cannot resolve anything real, and give up.

The majority of the time this happens, I need to spend many minutes commenting out blocks of code looking for the part of the app that is creating the confusion.

Because of the infinite stacking of structures within SwiftUI, it's readily possible to end up with a lot of lines of code with a lot of very important syntax structure that has to be correct to get compilation to happen. Thus, if I misspell symbols in particular I can end up with undefined types that seem to really confuse the compiler.

This is certainly not the case; the lookahead performed by the parser is fairly well-bounded and it's fairly trivial to detect when many statements should end even without explicit terminators based on what immediately follows. Parsing is not the performance bottleneck for compilation in any way that I'm aware of. If you doubt this, I'd encourage you to profile it (or, more simply, just run the code through swift-format—which uses the same parser—and observe the behavior).

The problems you're describing (especially since you're referring to SwiftUI) are more likely due to the type checker/constraint system trying to find a solution to something that has deeply nested structures and an error somewhere among them that makes it difficult to converge. It's a fair criticism in its own right (and the compiler authors have done a lot of great work already to improve it compared to past performance), but those problems are entirely unrelated to statement termination or trailing commas.

6 Likes