`if let` shorthand

Evolution Pitches
207

Thinking (just a little) more about it, and given:

  • The if let x = x { / guard let x = x else { use cases are ultra-frequent.
  • We can afford ultra-sugaring an ultra-frequent use case.
  • if var x = x { is less frequent.
  • I don't buy the argument that we must ship if var x { along with if let x {. Will we ship if ref x {, or if inout x { as well? IMHO, these should be pitched separately.
  • I'm not sure people want exactly if let x {. Maybe they mainly want to avoid the repetition of the variable name, and a very short yet legible syntax.

So I suggest dropping the var variant from this pitch, and just ship:

if x? { ... }
guard x? else { ... }

Short, sweet, and to-the-point: if let x = x is sugared to if x?.

  • if x? may be easier to understand by non-Swift-literate people (assuming they don't meet an optional bool too soon, and did not code in Ruby).

  • if x? brings back the question mark and makes case let x?: less odd (in this case the let is necessary in order to disambiguate between binding creation and matching with an existing binding).

If we want to support var or other modifiers in the future, we'll be able to support if var x? {, as well as if let x? {. The sugar chain will then read: if let x = x can be sugared to if let x?, which can be sugared to if x?. But this will live in another pitch.

1 Like