# 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:** 11

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [March 25, 2022, 12:33am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/203 "2022-03-25T00:33:32Z")

</div>

> [@1-877-547-7272](#):
>
> This seems like a very contrived example — most idiomatic Swift code doesn't require using an instance three times in one line.

Hmm...

```
// foo is external and doesn't know about CGPoint

if let pointOfIntersection {
    foo(pointOfIntersection.x, pointOfIntersection.y)
}

```

Do I really need to repeat "pointOfIntersection" 3 times in two lines?

This is much better IMHO:

```
if let v = pointOfIntersection {
    foo(v.x, v.y)
}

```

Anyway, one line or few lines - doesn't matter, example is showing the case where a variable is used several times in a short block, where "several" is as few as two. Short block is the key (if i was unfortunate to use and support code where a function spawns tens / hundreds lines i'd probably think differently.)

Here are a few relevant examples from my code:

example 1:

```
    let v = snapshot.itemIdentifiers(inSection: section)
    return indexPath.row < v.count - 1 ? v[indexPath.row + 1] : nil

```

example 2:

```
    if let v = details.leading {
        base = base.leading(v.leading)
    }
    if let v = details.weight {
        base = base.weight(v.weight)
    }
    if let v = details.opacity {
        base = base.opacity(v)
    }

```

example 3:

```
    if let v = visibleResources[key] {
        visibleResources[key] = v.visibleCount > 1 ? Resource(v.visibleCount - 1, v.version) : nil
    }

```

None of these examples would benefit from using longer names for "v" ("itemIdentifiers", "leading", "resource" correspondingly), at least not from my POV. I appreciate this is subjective.

---

<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 25, 2022, 12:54am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/204 "2022-03-25T00:54:24Z")

</div>

It’s subjective but ultimately you’re arguing against not only the Swift community but the industry as a whole. Additionally, you’ve made this point repeatedly so I’m not sure restating it yet again has much value.

---

<div class="post-metadata">

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

</div>

You can opt out of the new shorthand sugar and just do what you like, right?

This continues to work:

> [@tera](#):
>
> ```swift
> if let v = pointOfIntersection {
> foo(v.x, v.y)
> }
> 
> ```

---

<div class="post-metadata">

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

</div>

I must admit I hope this review is over soon. I’ve read the same arguments over and over and over and over and over. It’s clear there are some who are vehemently opposed. And likely a vast majority who will gladly use this shorthand when it is approved and available. As it should be. Because I would use it everyday, gladly, for the convenience and clarity, dare I say, that it will provide.

- What is your evaluation of the proposal?

I’m very positive. This will be a useful and very appreciated tweak to the language. Language is hard. But compared to all of the other stuff, generics, etc, this concept is easy as pie.

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

Definitely. The current pattern of redundancy is a wart on the language.

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

Yes.

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

I can’t think of an exactly analogous feature I’ve used, but many similar conveniences that have been appreciated.

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

I’ve followed every drop of hard spilled blood in the 200+ posts on this thread and the countless more in the previous sessions. Let’s put this baby to bed, by approving it and making this clear and useful shorthand available to those tens of thousands of coders who write swift day in and day out.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [March 25, 2022, 3:06am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/207 "2022-03-25T03:06:53Z")

</div>

```
if past_due_date { // and it is
	let finish_this = one_way_or_another
	something_we_can_all_agree_upon()!
}

```

---

<div class="post-metadata">

**Author:** ![Zhu\_Shengqi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zhu_shengqi/32/1199_2.png) [@Zhu\_Shengqi](https://forums.swift.org/u/Zhu_Shengqi)\
**Post date:** [March 25, 2022, 3:14am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/208 "2022-03-25T03:14:44Z")

</div>

> [@ben-cohen](#):
>
> What is proposed here is one of those boilerplate-reducing features. Clearly this is subjective: one person's clarity-defeating boilerplate is another's clarity-enhancing clarification. But quoting this passage shouldn't be taken as the "case closed, brevity is out" that it's often cited to confirm.

I agree that some subjectiveness is involved when people reviewing features according to Swift guidelines.

But regarding **the fact** that almost half the reviewers in the thread has +1 and the other half has -1 for this sugar syntax, I feel that **the Core Team is not doing their job** : such a controversial change should not come as the proposal for formal review (this thread is just as duplicated as the original pitch [`if let` shorthand - #57 by mtsrodrigues](https://forums.swift.org/t/if-let-shorthand/54230/57), with so many opposite arguments and no convergence can be reached). The Core Team should at least help ensure the formal proposal address the most significant concerns in the pitch stage and reaches the bar for a formal review, which is not the case.

I should not be the only person has this feeling.

---

<div class="post-metadata">

**Author:** ![Jean-Daniel](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Jean-Daniel](https://forums.swift.org/u/Jean-Daniel)\
**Post date:** [March 25, 2022, 6:18am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/209 "2022-03-25T06:18:02Z")

</div>

> [@jberry](#):
>
> It’s clear there are some who are vehemently opposed. And likely a vast majority who will gladly use it

Please do not speak for the other. Reading this thread, there is no evidence that one side is vastly superior in number to the other side.

> [@young](#):
>
> This continues to work:
> 
> > [@tera](#):
> >
> > ````swift
> > > if let v = pointOfIntersection {
> > foo(v.x, v.y)
> > }
> > > ```
> > 
> > ````

That's in part why I'm against this proposal. Having two ways to do the same thing is generally bad for a language as it source of fragmentation, code style flame war, stack overflow threads and more…

---

<div class="post-metadata">

**Author:** ![jeremy](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jeremy](https://forums.swift.org/u/jeremy)\
**Post date:** [March 25, 2022, 8:35am UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/210 "2022-03-25T08:35:46Z")

</div>

+1

I don't feel strongly about this, but I'll use it if it's available - I switched from `if let nonOptionalVariable = variable` to `if let variable = variable` as soon as that was possible, and I'll do the same in this case. I think the shorter version is clearer and easier to read. I generally prefer to use shorter forms of Swift syntax (closure syntax, omitting `return` etc.)

Effort: I've followed this thread and considered the arguments from both sides.

---

<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 25, 2022, 2:26pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/211 "2022-03-25T14:26:16Z")

</div>

> [@Zhu\_Shengqi](#):
>
> But regarding **the fact** that almost half the reviewers in the thread has +1 and the other half has -1 for this sugar syntax, I feel that **the Core Team is not doing their job** :

> [@Jean-Daniel](#):
>
> > [@jberry](#):
> >
> > It’s clear there are some who are vehemently opposed. And likely a vast majority who will gladly use it
> 
> Please do not speak for the other. Reading this thread, there is no evidence that one side is vastly superior in number to the other side.

I think it’s important not to mischaracterize one way or the other. As of this post, it is running about 60% for the proposal among posts that state a preference (approximate because not every post clearly states a preference, some posts are follow ups to previous posts, and some folks change their evaluation over time).

Of course, a proposal review isn’t a scientific sampling of all Swift programmers and the Core Team doesn’t simply look at the number of upvotes and downvotes to make their decision.

> [@Zhu\_Shengqi](#):
>
> such a controversial change should not come as the proposal for formal review (this thread is just as duplicated as the original pitch [`if let` shorthand - #57 by mtsrodrigues](https://forums.swift.org/t/if-let-shorthand/54230/57), with so many opposite arguments and no convergence can be reached).

Reading through the [Swift Evolution Process](https://github.com/apple/swift-evolution/blob/main/process.md) document, there’s nothing requiring a proposal to have a particular level of convergence of opinions before it is reviewed. My understanding is one purpose of the pitch phase is to bring out various objections, alternatives, and edge cases so that they may be addressed in the proposal before it is reviewed. But people still may have differing opinions about a proposal while it is being reviewed.

> [@Zhu\_Shengqi](#):
>
> The Core Team should at least help ensure the formal proposal address the most significant concerns in the pitch stage and reaches the bar for a formal review, which is not the case.

Reading over the objections to the proposal, they seem to largely fall into two categories:

The first being that this proposal favors 'brevity over clarity' and potential downsides of omitting the RHS. The proposal makes the case that this change achieves 'clarity through brevity' by eliminating boilerplate.

The second being a desire for an alternate shorthand syntax. Rationale why the proposed syntax was chosen over various alternatives is detailed in the proposal.

So, I think the proposal does address the most significant concerns which is what is expected of a proposal when it comes to review.

> [@Zhu\_Shengqi](#):
>
> I agree that some subjectiveness is involved when people reviewing features according to Swift guidelines.

I also agree and think there is always a degree of subjectiveness reviewing features. I think the review process gives people a chance to express their views of the pros or cons of a proposed feature, which gives the Core Team a variety of feedback and information they can evaluate in reaching their decision.

---

<div class="post-metadata">

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

</div>

> [@James\_Dempsey](#):
>
> Reading through the [Swift Evolution Process](https://github.com/apple/swift-evolution/blob/main/process.md) document, there’s nothing requiring a proposal to have a particular level of convergence of opinions before it is reviewed. My understanding is one purpose of the pitch phase is to bring out various objections, alternatives, and edge cases so that they may be addressed in the proposal before it is reviewed. But people still may have differing opinions about a proposal while it is being reviewed.

As others has pointed out, this proposal actually falls in [common rejected changes](https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md). I am not saying a convergence is required for a formal proposal to be reviewed, I am just stating the fact that this formal proposal contains so many opposite opinions (with 200+ comments!) as the previous pitch. I don't think there will be a convergence at the end (as with most of other accepted proposals).

> [@James\_Dempsey](#):
>
> Reading over the objections to the proposal, they seem to largely fall into two categories:
> 
> The first being that this proposal favors 'brevity over clarity' and potential downsides of omitting the RHS. The proposal makes the case that this change achieves 'clarity through brevity' by eliminating boilerplate.
> 
> The second being a desire for an alternate shorthand syntax. Rationale why the proposed syntax was chosen over various alternatives is detailed in the proposal.
> 
> So, I think the proposal does address the most significant concerns which is what is expected of a proposal when it comes to review.

For the first category, this is just your opinion (as with half of the reviewers in this thread). For the second category, my understanding is that some reviewers in the thread just think the existing `if let` binding works fine and nicely.

---

<div class="post-metadata">

**Author:** ![Iain\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/iain_smith/32/394_2.png) [@Iain\_Smith](https://forums.swift.org/u/Iain_Smith)\
**Post date:** [March 25, 2022, 3:06pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/213 "2022-03-25T15:06:25Z")

</div>

> What is your evaluation of the proposal?

+1 as written.

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

Borderline, but a nice UX improvement for many.

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

IMO yes, but I can see why others may disagree.

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

N/A

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

Read the proposal and followed the review thread.

---

<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 25, 2022, 3:08pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/214 "2022-03-25T15:08:29Z")

</div>

> [@Zhu\_Shengqi](#):
>
> > [@James\_Dempsey](#):
> >
> > Reading through the [Swift Evolution Process](https://github.com/apple/swift-evolution/blob/main/process.md) document, there’s nothing requiring a proposal to have a particular level of convergence of opinions before it is reviewed…
> 
> As others has pointed out, this proposal actually falls in [common rejected changes](https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md). I am not saying a convergence is required for a formal proposal to be reviewed, I am just stating the fact that this formal proposal contains so many opposite opinions (with 200+ comments!) as the previous pitch. I don't think there will be a convergence at the end (as with most of other accepted proposals).

I think there are are fair number of proposals where there isn't convergence of opinion of review participants at the end. A recent example would be [SE-0307: Allow interchangeable use of CGFloat and Double types](https://forums.swift.org/t/se-0307-allow-interchangeable-use-of-cgfloat-and-double-types/45756). People made their cases for and against and then the core team made their decision.

> [@Zhu\_Shengqi](#):
>
> > [@James\_Dempsey](#):
> >
> > > [@Zhu\_Shengqi](#):
> > >
> > > The Core Team should at least help ensure the formal proposal address the most significant concerns in the pitch stage and reaches the bar for a formal review, which is not the case.
> > 
> > Reading over the objections to the proposal, they seem to largely fall into two categories:
> > 
> > > The first being that this proposal favors 'brevity over clarity' and potential downsides of omitting the RHS. The proposal makes the case that this change achieves 'clarity through brevity' by eliminating boilerplate.
> > > 
> > > The second being a desire for an alternate shorthand syntax. Rationale why the proposed syntax was chosen over various alternatives is detailed in the proposal.
> > > 
> > > So, I think the proposal does address the most significant concerns which is what is expected of a proposal when it comes to review.
> 
> For the first category, this is just your opinion (as with half of the reviewers in this thread). For the second category, my understanding is that some reviewers in the thread just think the existing `if let` binding works fine and nicely.

I wasn’t really making an argument for or against this proposal here. I was saying that I think the proposal does address the significant concerns brought up in the pitch phase.

---

<div class="post-metadata">

**Author:** ![David\_Catmull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_catmull/32/1007_2.png) [@David\_Catmull](https://forums.swift.org/u/David_Catmull)\
**Post date:** [March 25, 2022, 3:54pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/215 "2022-03-25T15:54:54Z")

</div>

My 2¢:

I was initially opposed to this proposal, agreeing with all the common opposing arguments. Then I looked at my own code - using the Xcode regex `if let (\w+) = \1(,| \{)` - and considered whether I honestly thought the code would look better or worse using this shorthand. I confess I think I would like it better.

---

<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 25, 2022, 4:09pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/216 "2022-03-25T16:09:54Z")

</div>

> [@David\_Catmull](#):
>
> using the Xcode regex `if let (\w+) = \1(,| \{)`

Ooooh, thank you for this regex! I hadn't tried to do a regex search for this before.

Quick anecdotal data for this from Airbnb's iOS app codebase (over 2 million lines of Swift):

- 13,951 instances of `if let`
  - 3,752 (27%!) of those are `if let x = x`

- 15,294 instances of `guard let`
  - 6,195 (40%!) of these are `guard let x = x`

---

<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 25, 2022, 5:45pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/217 "2022-03-25T17:45:43Z")

</div>

> [@ksluder](#):
>
> ### `while let foo` considered harmful
> 
> `let foo` is obviously immutable. As proposed, `while let foo` introduces a new binding named `foo` with the unwrapped value of the outer binding. It is unclear when the binding happens. One can reasonably read `while let foo` as repeatedly checking the value of an immutable expression, implying the loop body would either never execute or repeat infinitely. In fact, this is the only reasonable interpretation if the outer optional `foo` is itself a `let` . And since `while var foo` introduces a new binding for `foo` that shadows the outer `foo` , how can a while loop body reasonably change the value of the outer `foo` and thus affect control flow? (Pointer aliasing notwithstanding.)
> 
> I suggest removing `while let/var foo` from the proposal. I would also be in favor of a source-breaking change that banned its long-form equivalent `while let/var foo = foo` .

Yesterday @Douglas_Gregor pointed out an instance where `while let foo = foo` is meaningfully useful: when an actor has a mutable optional `Task` property, the loop body `await`S that `Task`’s `value`, and the task might either clear out the task property or populate it with a new task:

```swift
actor foo {
  var task: Task<Int, Never>
  while let task = task {
    _ = await task.value // might clear out the task property or populate it with a new task
  }
}

```

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2022, 6:30pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/218 "2022-03-25T18:30:19Z")

</div>

> [@Zhu\_Shengqi](#):
>
> But regarding **the fact** that almost half the reviewers in the thread has +1 and the other half has -1 for this sugar syntax, I feel that **the Core Team is not doing their job** : such a controversial change should not come as the proposal for formal review (this thread is just as duplicated as the original pitch [`if let` shorthand - #57 by mtsrodrigues](https://forums.swift.org/t/if-let-shorthand/54230/57), with so many opposite arguments and no convergence can be reached). The Core Team should at least help ensure the formal proposal address the most significant concerns in the pitch stage and reaches the bar for a formal review, which is not the case.

I'll speak on behalf of the Core Team here, because "when is a proposal ready for review?" is something we have discussed numerous times. We've been very explicit that the existence of controversy is _not_ a reason to prevent a proposal from coming up for review. The reality is that some changes will be inherently controversial (especially with syntactic sugar), and no amount of pre-review discussion is going to change everyone's mind. The presence of controversy must not halt progress on the language.

When there is controversy in a pitch thread, it's the author's responsibility to capture the alternatives presented in Alternatives Considered with some commentary as to why they consider the proposed design to be the better choice. So while controversy doesn't prevent a proposal from moving into the review phase, _unaddressed_ controversy can prevent it because it means the feedback from the pitch thread hasn't been considered. It's the Review Manager's job to ensure that the major alternatives from the pitch discussions have been captured adequately in the proposal document. Given that most of the debate is a rehash of the same alternatives listed the proposal (`if let x?` especially), I think the proposal document's treatment of alternatives considered was sufficient for this review.

The job of the Core Team is to _decide_ and _guide_. We will evaluate the arguments presented here, in the pitch threads, and in the proposal, and make a decision on the proposal. That decision will provide rationale for that decision to aid future discussions.

Doug

---

<div class="post-metadata">

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

</div>

Perhaps pot luck, but the if let x = x percentage in my current client's app is almost the same, at 25%. And I suspect there are a handful of usages where we did rename the variable to something else, but if the sugar had existed, we would have used that form instead. And we have hundreds of `guard let self = self` that could be simplified.

---

<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 25, 2022, 7:14pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/220 "2022-03-25T19:14:47Z")

</div>

I know the review is technically over, and this topic has been fairly exhaustively discussed, but I’ll point out something I don’t recall seeing mentioned: by dropping the redundant half of `guard let longVariableName = longVariableName else { return }`, you alleviate the reader of the need to check for subtle differences or extra property accesses on the right hand side. I chose `guard` specifically for this example because those extra property accesses would be sandwiched between other syntax and thus much harder to visually scan for.

I suspect that if this feature had been in Swift from the beginning, it would be nearly universally adopted when possible, and the expanded `if let x = x` form would be a clear visual aid for readers to clue them in that something more than optional unwrapping is happening. I think adding that functionality is a justifiable goal of this new syntax, and we might even consider a linter rule or fixit to encourage migration and make up for lost time.

---

<div class="post-metadata">

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

</div>

> [@ksluder](#):
>
> I suspect that if this feature had been in Swift from the beginning, it would be nearly universally adopted when possible, **and the expanded `if let x = x` form would be a clear visual aid for readers to clue them in that something more than optional unwrapping is happening**. I think adding that functionality is a justifiable goal of this new syntax, and we might even consider a linter rule or fixit to encourage migration and make up for lost time.

I like that particular bit. If we ever end up changing the language in this area _one way or another_ I believe it would make sense to deprecate / prohibit "... let x = x" spelling if it is achieved by a shorthand spelling to the same effect. Thus any "... let x = x" being left would mean something extra is intended and will bring up attention.

My opposition to this proposal comes from the realisation that if it is approved just for "if/guard let/var x" case - it would make it much harder to pitch and agree on any future generalisations ("let/var x" shorthand that works outside if/guard contexts, explicit shadowing intent markers (e.g. " **override let** x = 123" and a shortcut version of it " **override let** x" - the latter in particular clashes with this proposal).

Within the boundaries of the proposal itself I see no harm supporting the very frequent use case `if let c = a.b.c` \<---\> `if let a.b.c`

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [March 25, 2022, 11:44pm UTC](https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805/222 "2022-03-25T23:44:52Z")

</div>

> [@Douglas\_Gregor](#):
>
> I'll speak on behalf of the Core Team here, because "when is a proposal ready for review?" is something we have discussed numerous times. We've been very explicit that the existence of controversy is _not_ a reason to prevent a proposal from coming up for review. The reality is that some changes will be inherently controversial (especially with syntactic sugar), and no amount of pre-review discussion is going to change everyone's mind. The presence of controversy must not halt progress on the language.

This is interesting, because in earlier times the core team was explicit that lack of "strong" consensus _did_ bar proposals coming to review. (See, for example, [#438](https://github.com/apple/swift-evolution/pull/438).)

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

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