# \`if let\` shorthand

**URL:** <https://forums.swift.org/t/if-let-shorthand/54230>\
**Category:** Pitches\
**Created:** [December 22, 2021, 10:23pm UTC](https://forums.swift.org/t/if-let-shorthand/54230 "2021-12-22T22:23:36Z")\
**Posts on this page:** 20\
**Page:** 7

<div class="post-metadata">

**Author:** ![JohnBlackburne](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnblackburne/32/8611_2.png) [@JohnBlackburne](https://forums.swift.org/u/JohnBlackburne)\
**Post date:** [January 1, 2022, 11:11am UTC](https://forums.swift.org/t/if-let-shorthand/54230/122 "2022-01-01T11:11:04Z")

</div>

I much prefer that, and can't think of a better word than `unwrap`. It also could be used in other ways, such as for force unwrapping. The following:

```swift
unwrap x { ... }

```

could stand for

```swift
_x = x!
{ 
    let x = _x
    ....
}

```

As with `x!` misusing it would result in a fatal error, but sometimes that's what you want.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [January 1, 2022, 3:34pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/123 "2022-01-01T15:34:39Z")

</div>

> [@Chris\_Lattner3](#):
>
> I agree that there is a problem to solve here, but I don't like the use of `if let x {` syntax for this.
> 
> 1. This is abusing the keyword `let` , muddying its meaning.
> 2. This begs the question of whether `if var x {` would do the same thing with a mutable copy/rebinding, which then begs more questions when we get to move semantics etc.
> 
> This is a fundamentally new concept. If it is important enough to add, it should be important enough to name. Why couldn't we use something like `if unwrap x {` or some other word for this? That would allow the documentation, explanation, and semantics to all be definable without building on pattern matching, value binding and other things that `let` carries with it.
> 
> -Chris

I’m surprised to hear you say these things, as I have nearly the direct opposite view.

1. This is using the `let` keyword in exactly its same existing meaning: to introduce a new immutable binding.

2. `if var x {` would do exactly and identically the same thing as `if var x = x {` does now. There is no ambiguity whatsoever.

3. We already have this concept in the language. The proposed change is just that the redundant retyping of the variable name need not be retyped redundantly.

• • •

I think it is worth considering that this proposal is not trying to construct a bikeshed. Rather, it is attempting to pave a [path of desire](https://en.wikipedia.org/wiki/Desire_path).

If you’ve ever been on, say, a snow-covered university campus, then you’ve probably witnessed the phenomenon where walking paths spontaneously appear in the winter through the action of many people all tromping the same way through the snow.

These are the paths people naturally desire to take. They were not part of the original plan for the sidewalks and trails of the campus. But once the main buildings are in use, people need to walk between them. And the snowy ground preserves their footsteps, revealing the well-trodden lines where a path really ought to be.

That’s what we’re seeing here, and have been seeing year after year since the initial release of Swift. People naturally expect there to be a path here. They attempt to walk this way because that’s where they want to go.

This feature is not a new building for the department of language theorists, nor a shed for them to park their bicycles in. Rather it is the natural path between two existing buildings, which ordinary programmers are continually surprised and dismayed to find a fence across, forcing them to go the long way round.

The language is designed in a way that makes people expect this to work already. The proposal aims to remove the fence, and put in a real pathway where people attempt and desire to walk.

• • •

Any alternative spelling would be actively worse. The proper spelling is the one that people already try to use and intuitively expect to work. That’s really the crux of the issue. This is a path of desire.

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [January 1, 2022, 4:08pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/124 "2022-01-01T16:08:00Z")

</div>

> [@Chris\_Lattner3](#):
>
> This is abusing the keyword `let` , muddying its meaning.

> [@Chris\_Lattner3](#):
>
> That would allow the documentation, explanation, and semantics to all be definable without building on pattern matching, value binding and other things that `let` carries with it.

Given the keyword `let` is already so overloaded, I don't see how this can really be described as abusing it. It is not a fundamentally new concept; it's a (very, very slight) shortcut for an existing use. That is always how it has been pitched and understood.

In fact, I'd say that `let` (and `var`) are the _only_ appropriate keywords for this. Introducing some new concept, like `unwrap x`, would muddy the meaning of the former keywords even further by obsoleting one of their most important features.

Basically, in a world with `if unwrap x`, our existing `if let x = y` syntax starts looking _less clear_ than it currently is. Why would you even write that instead of `if unwrap x = y`?

---

<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:** [January 1, 2022, 4:27pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/125 "2022-01-01T16:27:43Z")

</div>

> [@ben-cohen](#):
>
> > [@Saklad5](#):
> >
> > ```swift
> > if let element.optionalProperty {
> > // What even happens now?
> > }
> > 
> > ```
> 
> There are two very reasonable answers: either this declares a local variable called `optionalProperty` , or it doesn't compile. Both would be fine IMO.

I believe allowing this would give developers an easy path to sacrifice clarity for brevity, and so should _not_ compile.

In some very common cases, such as the `first` property of collections, the automatic name would almost never be a clear one, but would definitely be shorter to type:

```swift
guard let customers.first else { return }
// 'first' is the easiest name, but almost never a good name
print(first.firstName, first.lastName)

```

It also sets up the potential of conflicting implied names, for example:

```swift
guard let budgeted.total, let actual.total else { return }

```

or

```swift
guard let locales.first, let languages.first else { return }

```

Where the shorthand works on the first use but not the second.

The compiler could potentially work around this by creating up an automatic variable name such as `budgetedTotal`, `actualTotal`, `localesFirst`, and `languagesFirst`.

In some cases, that can lead to a descriptive variable name, in some cases like `localesFirst`, not a great name.

Finally, the construct `if let locales.first` is not declaring something called `locales.first`, whereas the shorthand as pitched, `if let foo`, is declaring a new variable `foo`, so stays true to the meaning of `let`. It's the right hand side of the current expression that is omitted with the shorthand, not the left hand side.

So, I hope this usage would be disallowed.

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 4:33pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/126 "2022-01-01T16:33:08Z")

</div>

> [@Nevin](#):
>
> `if var x {` would do exactly and identically the same thing as `if var x = x {` does now. There is no ambiguity whatsoever.

You're exactly illustrating the point I'm trying to make. Because you are anchored on the "if let" syntax, you go to "of course" we should support the "if var" analog.

That isn't clear to me at all - I don't see how "if var x {" is a good thing to support: it is transparently introducing new _mutable_ shadowed copies of unwrapped values with extremely tight syntax that is easy to overlook. This wouldn't be an "inout" binding to the element with the optional, which would betray a lot of expectations and introduce a lot of bugs.

Perhaps I should state my position from a different direction - we should decide if we want "if var" first. If not, then "if let" is clearly the wrong syntax. If we do want to support "if var" sugar, then I agree it makes sense to introduce the pair of "if let" and "if var" sugars.

-Chris

---

<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:** [January 1, 2022, 4:42pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/127 "2022-01-01T16:42:00Z")

</div>

> [@Chris\_Lattner3](#):
>
> we should decide if we want "if var" first. If not, then "if let" is clearly the wrong syntax.

I don’t follow this logic. I wouldnt think it unreasonable to limit this extremely targeted sugar to just `if let`.

---

<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:** [January 1, 2022, 4:54pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/128 "2022-01-01T16:54:26Z")

</div>

> [@Chris\_Lattner3](#):
>
> Perhaps I should state my position from a different direction - we should decide if we want "if var" first. If not, then "if let" is clearly the wrong syntax. If we do want to support "if var" sugar, then I agree it makes sense to introduce the pair of "if let" and "if var" sugars.

Thank you for restating this, it definitely clarifies things for me.

From what I can tell optional binding to a mutable variable has been available since Swift 3, so for about five years.

Has there been a lot of confusion, difficulty, or misuse of the existing `if var x = x` syntax?

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [January 1, 2022, 5:00pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/129 "2022-01-01T17:00:43Z")

</div>

I don't think there's confusion about `var` on optional-binding-condition clauses. However, there was confusion on `var` for function parameter position ([SE-0003](https://github.com/apple/swift-evolution/blob/main/proposals/0003-remove-var-parameters.md)), which, to me, looks very similar to the `var` version of this pitch.

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 5:40pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/130 "2022-01-01T17:40:03Z")

</div>

> [@James\_Dempsey](#):
>
> From what I can tell optional binding to a mutable variable has been available since Swift 3, so for about five years.
> 
> Has there been a lot of confusion, difficulty, or misuse of the existing `if var x = x` syntax?

I'm not making any statement about whether the `if var x = x` syntax is confusing. I'm suggesting that a new `if var x {` syntax could be. I'm not suggesting that we remove `if var x =` or `guard var x =`!

More generally, I suggest going back to basics on "why do we sugar things" and ask whether the rationale applies to "if var".

The goal of Swift language design isn't to minimize number of characters in code, it is to find a balance between "expressivity", and "readability". Readability isn't just "what does this line of code do" it is a deeper "what is the lifecycle of maintaining and evolving a codebase, particularly when it is worked on by multiple people, or the project spans years of development".

We _could_ sugar lots and lots of things - there is ample grammatical space to introduce new things into the language - but each new thing we introduce is something that Swift programmers will be expected to know/learn when they encounter them in a code base. Further, we have to consider what the implications are for the larger maintainability of the code base.

In the case of `if var x {`, my understanding is that `if var x = x {` is _FAR_ less common than the corresponding `if let x = x {` pattern, because it is extremely uncommon to make a mutable copy of something inside of an unwrap. Given that, the benefit of sugaring this is very low.

At the same time, the _cost of confusion_ is potentially very high. Both because some people will expect that this has something akin to an "inout" binding to the underlying value (when the original optional value is mutable). This confusion isn't possible with the 'if let' pattern because it is an immutable binding.

Am I wrong that `if var x = x {` is uncommon in swift code today?

-Chris

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 5:50pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/131 "2022-01-01T17:50:53Z")

</div>

> [@Nevin](#):
>
> I think it is worth considering that this proposal is not trying to construct a bikeshed. Rather, it is attempting to pave a [path of desire](https://en.wikipedia.org/wiki/Desire_path).
> 
> If you’ve ever been on, say, a snow-covered university campus, then you’ve probably witnessed the phenomenon where walking paths spontaneously appear in the winter through the action of many people all tromping the same way through the snow.

A small comment on this, but this is an _extremely_ dangerous way to approach language design, or design in general. If Swift followed the "give the customer what they are asking for" approach to design then we would be enjoying "everything is an object/class", "messages sent to nil are implicitly silenced" and many other "convenient" things that undercut the goals of the language.

While it is extremely important to listen to the problems and be open to new ideas, it is just as important to understand the framework, the long term direction of what you're trying to achieve and be willing to consider what the best way is to "solve the problem the customer is facing" even if it comes with a different solution than what they naturally gravitate to.

Given your specific example, sometimes you need to understand that your grass is going to be torn up with dozens of ad-hoc walking paths, and you should predict this and be willing to invest in proper infrastructure like bike paths etc.

-Chris

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [January 1, 2022, 6:06pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/132 "2022-01-01T18:06:22Z")

</div>

> [@Chris\_Lattner3](#):
>
> A small comment on this, but this is an _extremely_ dangerous way to approach language design, or design in general.

The system is already designed. People are already using it. The only question here is a minor convenience to the spelling.

It’s like laying out a rectilinear grid of sidewalks, and observing that after several years one particular corner is so heavily taken that a small diagonal path has been worn across the grass.

And then when someone suggests “Maybe we should make a little diagonal section of walkway there”, you say what?

“It’s extremely dangerous to give people a path where they want to walk”?

“Some people might think the path goes in a totally different direction”?

I think you’re making this into something way bigger than it actually is.

• • •

“`if let x {`” is **so** clear and **so** expressive, that people keep asking, year after year after year, why on earth it doesn’t work already. Why it wasn’t part of the original language when Swift was first released. It’s such a natural spelling for such a common concept, which fits so cleanly into the rest of the language, that **not** having it makes things feel somehow “off”.

If people completely new to Swift find themselves consistently expecting this spelling to work, and they all understand exactly what it should do, then what on earth are we trying to accomplish by persisting in directly contravening their common intuition?

There is zero danger of confusion here. The whole reason this feature keeps being proposed, is that it is such a glaringly obvious thing to have.

And by consistency, that extends to both the `guard` and `var` versions as well.

---

<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:** [January 1, 2022, 6:07pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/133 "2022-01-01T18:07:57Z")

</div>

> [@Chris\_Lattner3](#):
>
> Why couldn't we use something like `if unwrap x {` or some other word for this?

Introducing a whole new keyword for this seems like using a sledgehammer to tap in a nail to me. It would also be strange to introduce the term `unwrap` for this one specific form of unwrapping.

> [@Chris\_Lattner3](#):
>
> This is a fundamentally new concept.

"A new concept" is a fairly nebulous term but I can't see how this can be described as such. It's simple sugar that `if let x = x` can be written `if let x`. There are plenty of other places in the language where you can omit "obvious" things to reduce noise.

> [@Chris\_Lattner3](#):
>
> I don't see how "if var x {" is a good thing to support: it is transparently introducing new _mutable_ shadowed copies of unwrapped values with extremely tight syntax that is easy to overlook.

It's a good thing to support (and in keeping with what `if let x` would desugar to) for the same reason `if var x = x` is a good thing to support. Sometimes it's useful to have a mutable copy, and having to declare and assign it on another line is unhelpfully verbose.

> [@Chris\_Lattner3](#):
>
> [`if var x {` introducecs] extremely tight syntax that is easy to overlook

This seems like an exaggeration. The `var` in `if var x` is pretty obvious. I don't think the claim it would "betray a lot of expectations and introduce a lot of bugs." is credible. Does `if var x = x` do so? I don't believe so, and I don't think dropping the `= x` materially changes that.

---

<div class="post-metadata">

**Author:** ![Saklad5](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@Saklad5](https://forums.swift.org/u/Saklad5)\
**Post date:** [January 1, 2022, 6:09pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/134 "2022-01-01T18:09:19Z")

</div>

> [@Nevin](#):
>
> There is zero danger of confusion here. The whole reason this feature keeps being proposed, is that it is such a glaringly obvious thing to have.

My problem with it is implicit shadowing. I can’t think of any other example of that in the language (consider the way initializers often work, with explicit `self` assignment), and it comes with obvious readability pitfalls.

And I still don’t understand why this is helpful. Should this be done for for-loops too?

---

<div class="post-metadata">

**Author:** ![michelf](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michelf/32/1180_2.png) [@michelf](https://forums.swift.org/u/michelf)\
**Post date:** [January 1, 2022, 6:10pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/135 "2022-01-01T18:10:13Z")

</div>

My preference is for "`if let x`", but "`if unwrap x`" isn't bad either. Here's some code to get a feel of it:

```swift
if unwrap x {
   print(x)
}
if unwrap x, unwrap y, unwrap z {
   print(x + y + z)
} else if unwrap u {
   print(u)
}

```

I think it reads well. It might be less clear that you're creating a new variable with this (compared to `if let`), but this might not matter much if that variable is immutable and is shadowing the previous one.

The only (potentially surprising) situation exposing it's a new variable would be:

```swift
if unwrap x { // x is self.x here
   self.x = 1 // x is different from self.x here
}

```

Unfortunately, I don't think we can forbid this while keeping the model reasonable. This is why I'm hesitant to let go of the `let` (that signals a new variable) and replace it with `unwrap`.

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 6:20pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/137 "2022-01-01T18:20:56Z")

</div>

When ownership comes in, we will have borrowed values as arguments. It will be extremely natural to want to project a borrowed optional into a borrowed underlying element, exactly like "if let" does, but without the copy.

Is there a proposal for how this will be handled?

---

<div class="post-metadata">

**Author:** ![Saklad5](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@Saklad5](https://forums.swift.org/u/Saklad5)\
**Post date:** [January 1, 2022, 6:23pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/138 "2022-01-01T18:23:06Z")

</div>

The performance roadmap has a start. Maybe `if ref`, or whatever it ends up being called?

> [@A roadmap for improving Swift performance predictability: ARC improvements and ownership control](https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206/1):
>
> #### Borrow variables
> 
> When working with deep object graphs, it’s natural to want to assign a local variable to a property deeply nested within the graph:
> 
> ```swift
> let greatAunt = mother.father.sister
> greatAunt.sayHello()
> greatAunt.sayGoodbye()
> 
> ```
> 
> However, with shared mutable objects, such as global variables and class instances, these local variable bindings necessitate a copy of the value out of the object; either `mother` or `mother.father` above could be mutated by code anywhere else in the program referencing the same objects, so the value of `mother.father.sister` must be copied to the local variable `greatAunt` to preserve it independently of changes to the object graph from outside the local function. Even with value types, other mutations in the same scope would force the variable to copy to preserve the value at the time of binding. We may want to prevent such mutations while the binding is active, in order to be able to share the value in-place inside the object graph for the lifetime of the variable referencing it. We can do this by introducing a new kind of local variable binding that binds to the value in place without copying, while asserting a borrow over the objects necessary to access the value in place:
> 
> ```swift
> // `ref` comes from C#, as a strawman starting point for syntax.
> // (It admittedly isn't a perfect name, since unlike C#'s ref, this would
> // actively prevent mutation of stuff borrowed to form the reference, and
> // if the right hand side involves computed properties and such, it may not
> // technically be a reference)
> ref greatAunt = mother.father.sister
> greatAunt.sayHello()
> mother.father.sister = otherGreatAunt // error, can't mutate `mother.father.sister` while `greatAunt` borrows it
> greatAunt.sayGoodbye()
> 
> ```

Changing the subject back, I firmly believe that explicitly naming optional bindings is important for code clarity. And if there’s disagreement on that front, it would be better to use shorthand arguments ($0, etc.) instead of implicit shadowing. It’s not like the latter would provide any further information.

---

<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:** [January 1, 2022, 6:24pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/139 "2022-01-01T18:24:34Z")

</div>

> [@Chris\_Lattner3](#):
>
> Am I wrong that `if var x = x {` is uncommon in swift code today?

It depends what you mean by uncommon, but I searched a few large projects and it appeared several times in each one, and all the cases I checked looked legit. It's obviously a tiny number compared to `if let` but I'm not sure if that's relevant. The `if var` variant would be consistent, harmless (or at least not differently harmful to the existing desugared syntax), and useful.

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 6:45pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/140 "2022-01-01T18:45:39Z")

</div>

> [@ben-cohen](#):
>
> > [@Chris\_Lattner3](#):
> >
> > Am I wrong that `if var x = x {` is uncommon in swift code today?
> 
> It depends what you mean by uncommon, but I searched a few large projects and it appeared several times in each one, and all the cases I checked looked legit. It's obviously a tiny number compared to `if let` but I'm not sure if that's relevant

Right, I'm not arguing whether they are correct or not (surely var pattern bindings are useful!), I'm asking whether they are important to sugar. It sounds like the answer is "no", that sugaring them doesn't provide an important ergonomic benefit.

I come back to the harm of sugaring them. People seem to be content stating that "it is obvious what `if var x {` is defined by analogy to the existing syntax. But no one seem to be addressing the problem of "what does a reference to x mean in a scope mean in the face of this"? Changing x from immutable to mutable - or to be a mutable copy of mutable data that isn't tied its original value - isn't something you want to make lightweight and nearly invisible in source.

You also don't want to make it impossible - it is a useful thing (see above) but making it less visible isn't beneficial in my mind.

The reason I asked about the borrow version of this is that we're about to embark on a massive expansion of the type system for ownership. That expansion will need to answer all the same sorts of questions that we've had in the "copy things" part of Swift. Given that we've lived for years without sugaring this, it seems worthwhile to me to get the ownership support further along, to make sure we can come up with a coherent solution to works well with it as well as with Swift 1 features.

-Chris

---

<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:** [January 1, 2022, 6:47pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/141 "2022-01-01T18:47:43Z")

</div>

> [@ben-cohen](#):
>
> > [@Chris\_Lattner3](#):
> >
> > Am I wrong that `if var x = x {` is uncommon in swift code today?
> 
> It depends what you mean by uncommon, but I searched a few large projects and it appeared several times in each one, and all the cases I checked looked legit. It's obviously a tiny number compared to `if let` but I'm not sure if that's relevant. The `if var` variant would be consistent, harmless (or at least not differently harmful to the existing desugared syntax), and useful.

`if var x = ` is very uncommon; according to a quick GitHub search there are about 50 to 100 "if let x" for every "if var" usage (and in many cases "if var x = " usage is unjustified and is just a sloppy coding). I'd speculate "if var x = " is less needed than an ability to have a "var x: T" function parameter - something we had in original swift but then removed.

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\
**Post date:** [January 1, 2022, 6:48pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/142 "2022-01-01T18:48:37Z")

</div>

> [@Nevin](#):
>
> > [@Chris\_Lattner3](#):
> >
> > A small comment on this, but this is an _extremely_ dangerous way to approach language design, or design in general.
> 
> The system is already designed. People are already using it. The only question here is a minor convenience to the spelling.
> 
> It’s like laying out a rectilinear grid of sidewalks, and observing that after several years one particular corner is so heavily taken that a small diagonal path has been worn across the grass.

...

> [@Nevin](#):
>
> There is zero danger of confusion here. The whole reason this feature keeps being proposed, is that it is such a glaringly obvious thing to have.

Nevin: I am sure you mean well, but I would find your arguments more convincing if you addressed the points that I and other people are raising, instead of making undefended unilateral statements/claims that they are just wrong.

-Chris

[Previous page](https://forums.swift.org/t/if-let-shorthand/54230.md?page=6)

[Next page](https://forums.swift.org/t/if-let-shorthand/54230.md?page=8)