[Accepted] SE-0345: `if let` shorthand for shadowing an existing optional variable

[Douglas_Gregor]

Hello Swift Community,

The review of SE-0345 "if let shorthand for shadowing an existing optional variable" ended on March 22, 2022. The Core Team has decided to accept the proposal. Both the pitch and review threads for this proposal were very active, with well over 200 posts each. The Core Team would like to address a few of the discussion points and counter-proposals offered therein.

Bringing commonly-rejected changes up for review

It was noted that the shorthand syntax under review in SE-0345 is on the commonly-rejected list. It was added there in 2016, very early in the Swift Evolution process amidst rapid changes to the language in Swift 3. The commonly-rejected changes list is not an outright ban on discussing specific ideas, as the introductory paragraph notes:

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted. If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had. In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Given the prevalence of if let and guard let in Swift code, the persistent requests from the larger Swift community over many years to address this boilerplate, and a suitable proposal with a strong supporting pitch, SE-0345 has met this criteria. As part of this acceptance, the commonly-rejected list will be updated to remove the entry.

Alternative syntaxes

The clear majority of responses to the proposal were in favor of providing syntactic sugar to eliminate the if let x = x boilerplate, and much of the discussion centered around alternative syntaxes. The Core Team evaluated these alternatives and has approved the syntax as proposed.

The most-discussed alternative syntax was if let x?, which is directly addressed in Alternatives Considered in SE-0345. This syntax emphasizes the optional-unwrapping aspect of if let, rather than the shadowing aspect, and is more indicative of pattern matching (via if case let) than if let itself. James Dempsey provided insight into the ? sigil as well as the unwrap syntax:

I think the notion of an unwrap keyword, or requiring a sigil like ? , stems from the fact that the existing if let foo = bar or the shadowing version if let foo = foo is not immediately clear for a newcomer as there is no indication in the syntax that unwrapping is occurring. So the existing optional binding syntax could very easily be said to be unclear when first encountered.

The Core Team agrees that the optional-unwrapping behavior of if let can be a stumbling block for newcomers to Swift. However, that design decision is so deeply ingrained into Swift that it is unlikely to ever change, and any attempt to address that issue in one small place (such as providing if let x? as sugar for if let x = x) would further confuse the issue rather than improving upon it.

Thank you everyone who participated in the pitches and proposal review.

Doug Gregor
Review Manager