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

[cal (Cal Stephens)]

@Jumhyn

Just wanted to elaborate a bit on why I'm not super compelled by the proposal's arguments against if let foo?

Agreed that most of the style-related arguments here are pretty subjective. For the default case I think if let foo and if let foo? are both totally reasonable.

I do think if let foo meshes more nicely with other syntax / features adjacent to optional unwrapping. Support for explicit type annotations is one example currently included in the proposal / implementation:

if let foo: Foo { ... }

This falls out completely naturally from the change to the grammar, which is to just make the RHS optional. Disallowing this here would make the grammar a bit more complicated / less generalized.

For consistency with other lets / vars in the language, it seems desirable to support type annotations here unless we have a really compelling reason to disallow them. This was brought up in the pitch thread, as one example.

A future direction mentioned in the proposal is support for optional casting:

if let foo as? Bar { ... }

// as potential future shorthand for 
if let foo = foo as? Bar { ... }

I think both of these syntax extensions are a a bit more unnatural with an additional ? symbol:

if let foo?: Foo { ... }

if let foo? as? Bar { ... }

[ksluder (Kyle Sluder)]

@mtsrodrigues

I kind prefer if let value? because it's already used by switch statements in a similar way:

I agree. +1 on the feature, preference for the trailing question mark as a link to pattern matching.

[James_Dempsey]

• What is your evaluation of the proposal?
  +1

• Is the problem being addressed significant enough to warrant a change to Swift?
  Yes

• Does this proposal fit well with the feel and direction of Swift?
  Yes

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  I read the proposal in-depth and have followed and participated in the pitch thread. I have also read various threads over the years that propose something similar.

I prefer if let foo (and its cousin guard let foo) to all of the other proposed spellings. To me this proposal feels analogous to many of the closure syntax shorthands where items are able to be omitted with no sigil added to indicate the omission.

One thing I would note is that currently the if let foo = foo idiom is not mentioned at all in The Swift Programming Language book.

I think that, similar to how the book walks through the various shorthands that can be used with closures, it would be great to have a similar thing in the section that introduces optional bindings:

• Starts with if let foo = bar as it currently does.
• Introduces the Swift idiom if let foo = foo and explains the new variable shadows the original.
• Introduces the if let foo shorthand.

I think including the common if foo = foo idiom when introducing optional binding would be very helpful to all newcomers to Swift regardless of whether this proposal is accepted, but would be particularly important to add it to explain this new shorthand if adopted.

[Jumhyn (Frederick Kellison-Linn)]

@cal

This falls out completely naturally from the change to the grammar, which is to just make the RHS optional. Disallowing this here would make the grammar a bit more complicated / less generalized.

FWIW, I'm very uncompelled by the goal of keeping the formal grammar as simple as possible compared to producing a good language model.

@cal

For consistency with other let s / var s in the language, it seems desirable to support type annotations here unless we have a really compelling reason to disallow them.

As I mentioned before, I think if let foo: Bar really starts to depart from the simple model of if let foo. It doesn't read as an optional unwrapping nearly as naturally to me. It's not even clear to me that it's particularly desirable to maintain the same name while changing the type—in this example, wouldn't the long-hand version be more natural as "if let bar: Bar = foo"?

@cal

A future direction mentioned in the proposal is support for optional casting:

if let foo as? Bar { ... }

// as potential future shorthand for 
if let foo = foo as? Bar { ... }

I think both of these syntax extensions are a a bit more unnatural with an additional ? symbol:

if let foo?: Foo { ... }

if let foo? as? Bar { ... }

On the flip side, that the syntax seems slightly more unnatural doesn't worry me. I don't think I've ever seen an if let with a type annotation 'in the wild', and as with the generics proposals, I don't think this sugar needs (or even should) support every possible construct where a user might write the token sequence foo = foo. When there's more going on than a simple unwrapping, I think comprehension is hurt by trying to cram everything into as few tokens as possible (e.g., rebinding, dynamic cast/type coercion, and optional unwrap). That if let foo more naturally supports these extensions just doesn't feel like a feature to me.

[James_Dempsey]

@jpmhouston

The problem with if let a is that it's absolutely symbol salad, it omits entirely half of the statement that is meant: "if (i can) let a (equal itself)". But it doesn't only detract from the legibility of these "if" statement, it undermines every other use of "let": So is just let a valid Swift too? Can I trust what "let" and "var" mean?

This already exists with if let foo = foo since just plain let foo = foo is not valid Swift. This hasn't seemed to be a significant problem with people not able to trust what let and var mean.

That said, I agree that if let a = b may not be the optimal syntax for optional binding. Newcomers need to learn that if let and if var are not the same as just let and var. But as I describe in more detail below, I think if let would be difficult to move away from at this point.

@jpmhouston

In the discussion I tried to endorse the addition of the "unwrap" keyword, and its potential to increase readability in this use case and possibly others.

One drawback is that it doesn't allow the choice between creating an immutable or (much more rare) mutable unwrapped variable that let and var provide.

But beyond that, I think introducing a new keyword for this purpose introduces more complexity than it resolves.

If the keyword is only used as a synonym for if let x = x , then it needs to be mixed and matched with if let -style bindings when multiple items are bound in a single statement:

if unwrap user, let defaultAddress = user.shippingAddresses.first { }

This is easily a point of confusion to people new to the language, but it would be a natural question for everyone to ask "Why can't I use unwrap in both cases? Why do I have to use let sometimes and unwrap sometimes?"

It wouldn't seem to make much sense to be able to use unwrap in one case and not the other. To fix this friction, a next step would be to allow unwrap instead of let for optional binding:

if unwrap user, unwrap defaultAddress = user.shippingAddresses.first { }

And, on its own, I think that reads well.

But, without a source breaking change, if unwrap would always need to exist alongside the existing if let . Some projects will prefer one or the other, essentially creating two dialects of Swift for an incredibly common construct. And to move between codebases, everyone will need to know and understand both syntaxes (and if working on different projects keep track of which project prefers which style).

I think in practice both the "mix and match" style and the "both coexist" style would add a good deal of unwanted complexity over the current state of things and over the proposed solution.

[chockenberry (Craig Hockenberry)]

What is your evaluation of the proposal?

Is it cheating to say +∞?

Is the problem being addressed significant enough to warrant a change to Swift?

Not only is it a significant enough change for Swift, it's a significant change for my source code. I suspect a lot refactoring of if let x = x code is in my future.

Does this proposal fit well with the feel and direction of Swift?

One of the early goals of Swift was to make a language that was approachable both to developers coming from other languages and, more importantly, to beginners. I think this proposal helps with that by being more readable and an gentler introduction into optional values.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More than a quick reading, less than in-depth study.

I've been following this work since the beginning. I think @cal has done a great job of taking that initial idea and making it concrete with both a proposal and implementation.

I'm looking forward to using this new feature.

-ch

[bondo (Joachim Bondo)]

+∞ to what @chockenberry says.

[woolsweater (Josh Caswell)]

@James_Dempsey

This already exists with if let foo = foo since just plain let foo = foo is not valid Swift.

It may be a minor point, but this is not accurate. That is legal, in similar circumstances to the proposed functionality. For example:

struct S {
  var foo: Int

  func bar() {
    let foo = foo
  }

  func baz(_ quux: Bool) {
    let quux = quux
  }
}

What's not legal is shadowing a name in the same scope.

[filip-sakel]

@cal

I think both of these syntax extensions are a a bit more unnatural with an additional ? symbol:

if let foo?: Foo { ... }

if let foo? as? Bar { ... }

I think these extension could still look natural with the if let foo? syntax:

if let (foo as Foo)? {} 

// "if let foo?” is not mutually exclusive with this syntax
if let foo as? Bar {}

For what it’s worth, I don’t find if let foo?: Foo that bad, considering that most Swift users will see this code with syntax highlighting.

[davbeck (David Beck)]

+1 I think this looks great and is a great fit for Swift.

For reference, in Typescript you would check for optionality this way:

if foo != null {
  // the compiler now treats foo as non optional
}

It makes sense for a language based on JS, but this accomplishes the same level of conciseness while being much more Swift like.

[James_Dempsey]

Yes, I did mean in the same scope. Thank you for pointing this out.

I think my overall point remains that sometimes let foo = foo is valid Swift and sometimes it is not and that hasn't seemed to be a significant problem with people not able to trust what let and var mean.

[Ben_Cohen]

Similarly, let a is invalid but only because the type of a cannot be inferred. let a: Int is perfectly valid leaving initialization of a to later.

[aerobounce]

Happy to see this in review.
The proposal is very clear, easy to understand and thank you for your effort.

• What is your evaluation of the proposal?

Pretty nice:

It doesn't introduce new keyword nor (pre/post)-fix operator.

• Easy to adopt.
• It doesn't make sense to introduce new syntax specifically only for this situation (unwrap optional and shadow it) when there's one which have the same meaning and widely understood by that way (if/guard let is there to unwrap optional).
• Also it also doesn't make sense to do it specifically at this level. switch ... > if case let > if let ... and why new keyword from here all of a sudden?

Instead, it solves the problem by introducing a new grammar, which is smart because:

• Grammar of LHS remains intact.
  • This means you can type it: if let a: Int { ...
• This alternative will be new confusing syntax: if let a?: Int
• You can opt-in this feature by just omitting the RHS of your statements.
  • Also easy to revert if needed to.
• This is opt-in.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. This will allow the compiler to do the routine we manually do currently.

• Does this proposal fit well with the feel and direction of Swift?

From the top to the bottom, yes. I'm seeing a bit of similarity in Type Inference and also in switch:

var value: Int? = 0

switch value {
case let .some(value): print(value)
case .none: break
}

// shorthand:
if let value { ...

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No experience of a similar feature in other languages.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Throughout the pitch of this proposal and the similar discussion thread mentioned in the proposal.

[sir_mordred (Oğuzhan Yiğit)]

+1 for ergonomic improvement but -1 for lots-of-sugared-syntax-burden language, as a beginner swift user and developer, in my opinion swift's readability is getting worse day by day because of A LOT OF alternative syntaxes/sugared syntaxes

like the following:

guard let if let x lotsOfAnnotators lotsOfWeirdInitializers blahblahblah

and it seems no one consider simplicity and clearness of language, just adding bunch of sugars/weirdo features-that-makes-less-typing etc.

im not opposing to syntactic sugars but IMO creating lots of alternative ways (syntaxes/sugars) to do one thing is a bad approach, of course alternatives makes language more flexible but IMO it makes language less readable and less simple also (some sort of trade-off balance)

thanx
regards

[xedin (Pavel Yaskevich)]

I'd like to suggest a clarification to the Detailed Design section - the proposal states that only valid identifiers are going to be accepted but it should also not an exception - a static variable in instance context just like it does for member references e.g.:

struct S {
  static var x: Int? = 42

  func test() {
    if let x {
      print(x)
    }
  }
}

This is going to produce the following diagnostic - static member 'x' cannot be used on instance of type 'S' with an incorrect fix-it:

if let x {
       ^
       S.

Implementation has to adjust diagnostic for static member references to account for new syntax and suggest = S.x instead of just S. for reference to x.

[BDC]

Would this allow implicit self in a closure then? I worry that some developers use the explicit self in closure error as a helpful reminder that you might be capturing something you don't intend to.

doSomethingWithCompletion { _ in
    guard let localVar else { return }
}

is inherently the same as

doSomethingWithCompletion { _ in
    guard let localVar = localVar else { return } //this would need to be `guard let localVar = self.localVar...`
}

But in that case you'd get a compiler error saying that localVar in closure requires explicit use of 'self' to make capture semantics explicit, which I am in favor of.

[cal (Cal Stephens)]

As of SE-269 explicit self is only required when the closure is escaping and self is a reference type. So if self is a value type, or if the closure is non-escaping, then implicit self is totally fine here.

For escaping closures where self is a reference type, we do still need explicit self. That isn't possible with this syntax as proposed, but one option is to put [self] in the capture list to enable implicit self in the body:

doSomethingWithCompletion { [self] _ in
    // implicit self is allowed in the body since self was already 
    // captured explicitly in the capture list
    guard let localVar else { return }
}

(sidenote, explicit self is currently always required if the closure is using weak self, but I have another proposal up that would lift that restriction: Add proposal for allowing implicit self for weak self captures by calda · Pull Request #1506 · apple/swift-evolution · GitHub)

[Jon_Shier]

• What is your evaluation of the proposal?

+0.25

I don't think it's detrimental, I just don't think it's very valuable, and I prefer the if let x? syntax.

• Is the problem being addressed significant enough to warrant a change to Swift?

Kind of.

Frankly, any code base where this has a significant impact should instead be evaluating how to minimize their usage of optional values in the first place. Optionals are extremely overused, especially by developers coming from languages which have always required null checking, as they see them as equivalent. However, they're most often a failure in domain modeling and a large number should just be removed, as the values aren't truly optional (as often seen in HTTP APIs) or there would be better representations (no Bool? please).

• Does this proposal fit well with the feel and direction of Swift?

Kind of. I think it conflicts with Swift's goal of clarity over succinctness, but its impact is ultimately subjective, especially since you can keep using the old syntax.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Haven't used such a language.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Participated in the pitch, read the proposal.

[phoneyDev (Stern)]

-1

This just seems to be terseness for terseness sake. It doesn't let you do anything new that couldn't be done before. I agree that it's symbol salad.

Other programming languages have a coding style where short variable names and abbreviations are commonly used. The Swift style guide argues against this and for a fluent coding style. This proposal seems to be going in the short variable name direction and not in the Swift style direction.

[bnyu]

+1 for if let x?