# \[Syntax\] Default name for optional binding self and other properties

**URL:** <https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394>\
**Category:** Pitches\
**Tags:** optional\
**Created:** [July 29, 2019, 2:39pm UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394 "2019-07-29T14:39:35Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![lxd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lxd/32/8543_2.png) [@lxd](https://forums.swift.org/u/lxd)\
**Post date:** [July 29, 2019, 2:39pm UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/1 "2019-07-29T14:39:35Z")

</div>

**Introduction**

Optional binding is one of the most popular ways to unwrap an optional value. Moreover, when the optional is in the current scope, like self, it's standard practice to initialize the bound constant with the same name. Consider the following very common scenario occurring inside closures that weakly capture self:

```swift
guard let self = self else {
    return
}

```

**Proposed solution**

Because this approach is so popular I propose to introduce the option to omit the assignment and implicitly use the same name:

```swift
guard let self else {
    return
}

```

This behavior would obviously extend to other control flow statements:

```swift
if let error {
    preconditionFailure(error.localizedDescription)
}

```

**Motivation**

This would enforce good practice by default. Using a different name, like `strongSelf` adds unnecessary complexity in my opinion. In the spirit of progressive disclosure, customizing the name of the bound constant could be considered an advanced feature that novice language users don't have to know about when getting started.

**Inspiration**

Capture lists follow the same implicit naming pattern:

```swift
[weak self = self]

```

Personally, because I encounter the weak self dance so frequently, this change would make code simpler to read and reason about. What do you think?

---

<div class="post-metadata">

**Author:** ![suyashsrijan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/suyashsrijan/32/5292_2.png) [@suyashsrijan](https://forums.swift.org/u/suyashsrijan)\
**Post date:** [July 29, 2019, 2:44pm UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/2 "2019-07-29T14:44:53Z")

</div>

This has been discussed many times in the past:

1. [Easy strongified weak `self` in closures](https://forums.swift.org/t/easy-strongified-weak-self-in-closures/16767)
2. [Syntactic sugar for simplifying guards](https://forums.swift.org/t/syntactic-sugar-for-simplifying-guards/24003/)
3. [Pitch: Syntactic sugar for circumventing closure capture lists](https://forums.swift.org/t/pitch-syntactic-sugar-for-circumventing-closure-capture-lists/23425/)
4. [Proposal: weakStrong self in completion handler closures](https://forums.swift.org/t/proposal-weakstrong-self-in-completion-handler-closures/161)
5. [[Proposal Update 1] A simplified notation for avoiding the weak/strong dance with closure capture lists](https://forums.swift.org/t/proposal-update-1-a-simplified-notation-for-avoiding-the-weak-strong-dance-with-closure-capture-lists/1415/)

IMHO it's not worth adding complexity to the language to save a few keystrokes in this scenario. The fact that you have to explicitly do this "dance" is for a good reason (clarity over terseness, which is important when dealing with weak/strong references).

---

<div class="post-metadata">

**Author:** ![jarod](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jarod/32/364_2.png) [@jarod](https://forums.swift.org/u/jarod)\
**Post date:** [July 30, 2019, 12:50am UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/3 "2019-07-30T00:50:40Z")

</div>

I've been quietly hoping for a long time that we would eventually come around to this. I think it comes up a lot because it's a common pain point -- I know that I write `if let x = x` and `guard let x = x` all the time, and I always find it tedious. The main argument against the proposal as I understand it is that the proposed syntax lacks clarity, but I really don't find that to be true. It seems perfectly reasonable and clear to me.

Has this ever made it beyond the pitch phase? I'd really like to see it go through the full proposal process and get the core team to weigh in.

---

<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:** [July 30, 2019, 1:18am UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/4 "2019-07-30T01:18:20Z")

</div>

Does it extend to `var` too?

```
if var error { ... }

```

(The current syntax works with `var`.)

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [July 30, 2019, 4:45am UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/5 "2019-07-30T04:45:01Z")

</div>

> [@michelf](#):
>
> Does it extend to `var` too?
> 
> ```swift
> if var error { ... }
> 
> ```

tt should!

---

<div class="post-metadata">

**Author:** ![drumnkyle](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/drumnkyle/32/1769_2.png) [@drumnkyle](https://forums.swift.org/u/drumnkyle)\
**Post date:** [July 31, 2019, 12:26am UTC](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394/6 "2019-07-31T00:26:56Z")

</div>

Yeah, I do this all the time. It reminds me a bit of the idea of having the automatically synthesized newValue in a didSet. It seems to have merit for me to save keystrokes and is clear what you’re doing. I’m usually for clarity over brevity but the duplication of the property name doesn’t really do anything for clarity IMHO.