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

**URL:** <https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805>\
**Category:** Proposal Reviews\
**Created:** [March 8, 2022, 11:24pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805 "2022-03-08T23:24:15Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![cal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cal/32/35557_2.png) [@cal](https://forums.swift.org/u/cal)\
**Post date:** [March 10, 2022, 2:57pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/41 "2022-03-10T14:57:25Z")

</div>

> [@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:

```swift
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 `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. This was [brought up in the pitch thread](https://forums.swift.org/t/if-let-shorthand/54230/39), as one example.

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

```swift
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:

```swift
if let foo?: Foo { ... }

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

```

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [March 10, 2022, 3:15pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/42 "2022-03-10T15:15:46Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [March 10, 2022, 3:43pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/43 "2022-03-10T15:43:43Z")

</div>

- 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.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [March 10, 2022, 4:09pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/44 "2022-03-10T16:09:06Z")

</div>

> [@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:
> 
> ```swift
> 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:
> 
> ```swift
> 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.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [March 10, 2022, 4:14pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/45 "2022-03-10T16:14:07Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![chockenberry](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chockenberry/32/17106_2.png) [@chockenberry](https://forums.swift.org/u/chockenberry)\
**Post date:** [March 10, 2022, 4:28pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/46 "2022-03-10T16:28:05Z")

</div>

**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](https://forums.swift.org/t/lets-fix-if-let-syntax/48188). 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

---

<div class="post-metadata">

**Author:** ![bondo](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bondo/32/14117_2.png) [@bondo](https://forums.swift.org/u/bondo)\
**Post date:** [March 10, 2022, 4:44pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/47 "2022-03-10T16:44:34Z")

</div>

+∞ to what @chockenberry says.

---

<div class="post-metadata">

**Author:** ![woolsweater](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/woolsweater/32/2402_2.png) [@woolsweater](https://forums.swift.org/u/woolsweater)\
**Post date:** [March 10, 2022, 4:57pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/48 "2022-03-10T16:57:48Z")

</div>

> [@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:

```swift
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.

---

<div class="post-metadata">

**Author:** ![filip-sakel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/filip-sakel/32/8697_2.png) [@filip-sakel](https://forums.swift.org/u/filip-sakel)\
**Post date:** [March 10, 2022, 5:11pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/49 "2022-03-10T17:11:20Z")

</div>

> [@cal](#):
>
> I think both of these syntax extensions are a a bit more unnatural with an additional `?` symbol:
> 
> ```swift
> if let foo?: Foo { ... }
> 
> if let foo? as? Bar { ... }
> 
> ```

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

```swift
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.

---

<div class="post-metadata">

**Author:** ![davbeck](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davbeck/32/32237_2.png) [@davbeck](https://forums.swift.org/u/davbeck)\
**Post date:** [March 10, 2022, 5:14pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/50 "2022-03-10T17:14:19Z")

</div>

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

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

```nohighlight
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.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [March 10, 2022, 5:14pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/51 "2022-03-10T17:14:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [March 10, 2022, 5:22pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/52 "2022-03-10T17:22:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![aerobounce](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aerobounce/32/14175_2.png) [@aerobounce](https://forums.swift.org/u/aerobounce)\
**Post date:** [March 10, 2022, 6:04pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/53 "2022-03-10T18:04:49Z")

</div>

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](https://docs.swift.org/swift-book/ReferenceManual/Types.html#ID457) and also in switch:

```swift
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.

---

<div class="post-metadata">

**Author:** ![sir\_mordred](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sir_mordred/32/15456_2.png) [@sir\_mordred](https://forums.swift.org/u/sir_mordred)\
**Post date:** [March 10, 2022, 6:58pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/54 "2022-03-10T18:58:47Z")

</div>

+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

---

<div class="post-metadata">

**Author:** ![xedin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/xedin/32/309_2.png) [@xedin](https://forums.swift.org/u/xedin)\
**Post date:** [March 10, 2022, 8:48pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/55 "2022-03-10T20:48:04Z")

</div>

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.:

```swift
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:

```swift
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`.

---

<div class="post-metadata">

**Author:** ![BDC](https://avatars.discourse-cdn.com/v4/letter/b/2bfe46/32.png) [@BDC](https://forums.swift.org/u/BDC)\
**Post date:** [March 10, 2022, 9:03pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/56 "2022-03-10T21:03:48Z")

</div>

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.

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

```

is inherently the same as

```swift
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.

---

<div class="post-metadata">

**Author:** ![cal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cal/32/35557_2.png) [@cal](https://forums.swift.org/u/cal)\
**Post date:** [March 10, 2022, 9:13pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/57 "2022-03-10T21:13:36Z")

</div>

As of [SE-269](https://github.com/apple/swift-evolution/blob/main/proposals/0269-implicit-self-explicit-capture.md) 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:

```swift
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](https://github.com/apple/swift-evolution/pull/1506))

---

<div class="post-metadata">

**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\
**Post date:** [March 10, 2022, 10:22pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/58 "2022-03-10T22:22:27Z")

</div>

> - 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.

---

<div class="post-metadata">

**Author:** ![phoneyDev](https://avatars.discourse-cdn.com/v4/letter/p/49beb7/32.png) [@phoneyDev](https://forums.swift.org/u/phoneyDev)\
**Post date:** [March 11, 2022, 1:03am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/59 "2022-03-11T01:03:26Z")

</div>

-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.

---

<div class="post-metadata">

**Author:** ![bnyu](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bnyu/32/12299_2.png) [@bnyu](https://forums.swift.org/u/bnyu)\
**Post date:** [March 11, 2022, 1:14am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/60 "2022-03-11T01:14:03Z")

</div>

+1 for `if let x?`

[Previous page](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805.md?page=2)

[Next page](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805.md?page=4)