A while back, I showed interest in picking up GitHub issue #48100 (or SR-5528), which suggests allowing multiple typealias declarations in a single statement—kind of like how let and var already work. At the time, I got busy and couldn’t continue, but I finally have some time to finish this up.
Recap
Swift currently requires each typealias to be declared separately:
However, Swift allows multiple let and var declarations in a single statement:
let x = 10, y = 20
var a = "hello", b = "world"
The idea is to make typealias consistent, so we could write:
typealias Tomayto = Tomahto, Potayto = Potahto
What Do You Guys Think?
It seems like a small quality-of-life improvement. More importantly, it would make the language more consistent.
Can any of you help me navigate the thousand lines scattered across 15 to 20 files in lib/Parse?
Also, do you think this needs a full Swift Evolution Proposal (SEP)? I think it doesn’t, since it’s only a minor change, but I’d love to hear your thoughts!
In my view for consistency it would be better to remove this pattern:
let x = 10, y = 20
Not going to happen now but it should have been left out of the language. If you want two definitions on a line either use two statements separated by a semicolon or a tuple:
Yeah, but defaults are less frequently used than conformance requirements, and it would be strange if , had a different interpretation in the two situations.
Also, while we’re pontificating about syntax: it’s too late to change it now and it’s a very minor point anyway, but I kind of wish things evolved in the opposite direction, without the ability to declare multiple enum elements in a single case and similar trickery.
Similarly, while pattern destructuring is useful in local context, it might have been better if stored properties did not support complex patterns and instead just had to be declared one at a time with var or let:
struct Foo {
var (x, y) = something()
}
The reason is that this generality actually introduces some inconsistency rather than eliminating it. For example, stored property initial values become default arguments in the memberwise initializer in simple cases, but not with the above, because a single expression initializes two variables.
Also, computed properties cannot have pattern bindings for obvious reasons, but this also extends to constructs which are declared like stored properties but lower to computed properties, such as property wrappers and lazy properties:
As someone who's written quite a few macros now, places where there's a lot of variance in surface syntax for the same semantic meaning are the bane of my existence. I'm against adding this for the simple reason that it will make processing typealiases in macros harder, for very little benefit to authors of code.
(As various other people have mentioned, I'd be in favor of removing "multiple binding" for variables, and "multiple case" for enums from the language in a future major version)