I’m happy to see this proposal, and I’m a +1 on the idea.
The then keyword does indeed invite bikeshedding…but honestly it’s far better than anything I’m able to come up with, both for readability / fluency and for its impact on the language. I’m a definite -1 on trying to shoehorn yield into this role, don’t like my own result proposal from the original SE-0380 discussion, and haven’t heard any alternatives that come remotely close to working any better. (I spent a minute considering yielding, and my conclusion was “yuck.”)
While the “last expression” rule works fine in Ruby and Rust, and while I still hear Joe Groff’s voice in my head (I think it was Joe) saying that maybe type checking reduces the unexpected accidental return values it causes in Ruby, ultimately my gut says that it’s just not very Swift-y.
This proposal’s use of then does fly in the face of the meaning of then in existing languages with if…then…else syntax — then more typically marks the end of the condition and the beginning of the first branch, not the end of a branch — but somehow it kind of works. I’m good with it.
I like the do portion of the proposal very well. The closure tricks we use now are fine, usually, mostly, but have always sat awkwardly with me. The proposal is a clear improvement.
Looking over my original concerns with SE-0380, this proposal squarely addresses everything I wrote about my first concern in that post.
At some point, I’d love to see that second concern addressed as well. I still think my suggestion of additionally allowing condition subexpressions anywhere they’re directly enclosed by parens was a good suggestion, so that e.g. this works:
print(
if thingy.isWacky {
"Wacky thingy \(thingy.name)!"
} else {
"nothing to see here"
}
)
…but that’s for another proposal.