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.
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
I think the notion of an
unwrapkeyword, or requiring a sigil like
?, stems from the fact that the existing
if let foo = baror the shadowing version
if let foo = foois 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.