# SE-0365: Allow implicit self for weak self captures, after self is unwrapped

**URL:** <https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040>\
**Category:** Proposal Reviews\
**Created:** [July 18, 2022, 3:37pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040 "2022-07-18T15:37:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\
**Post date:** [July 18, 2022, 3:37pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/1 "2022-07-18T15:37:30Z")

</div>

Hello Swift Community,

The review of [SE-0365: Allow implicit self for weak self captures, after self is unwrapped](https://github.com/apple/swift-evolution/blob/main/proposals/0365-implicit-self-weak-capture.md) begins now and runs through August 1st, 2022.

Reviews are an important part of the Swift evolution process. All review feedback should either be on this forum thread or, if you would like to keep your feedback private, directly to the review manager by DM. When messaging the review manager directly, please keep the proposal link at the top of the message and the evolution identifier in the subject line.

## What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at: [https://github.com/apple/swift-evolution/blob/main/process.md](https://github.com/apple/swift-evolution/blob/main/process.md)

Thank you for helping review this proposal.

Saleem Abdulrasool  
Review Manager

---

<div class="post-metadata">

**Author:** ![Sajjon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sajjon/32/12044_2.png) [@Sajjon](https://forums.swift.org/u/Sajjon)\
**Post date:** [July 18, 2022, 3:50pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/2 "2022-07-18T15:50:24Z")

</div>

+1  
Feels like a natural ergonomic improvement.

Extra nice given [SE-0345](https://github.com/apple/swift-evolution/blob/main/proposals/0345-if-let-shorthand.md) ! Woho!

---

<div class="post-metadata">

**Author:** ![Jon889](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon889/32/3139_2.png) [@Jon889](https://forums.swift.org/u/Jon889)\
**Post date:** [July 18, 2022, 5:40pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/3 "2022-07-18T17:40:31Z")

</div>

+1

Seems very natural to have this.

---

<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:** [July 18, 2022, 6:25pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/4 "2022-07-18T18:25:48Z")

</div>

> What is your evaluation of the proposal?

Strongly agreed, as written.  
Its intention is very clear, and robust.

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

Yes. It makes codes much cleaner.

Moreover it is not just a yet another sugar if I understand correctly.  
It solves a common pitfall\* at last, by cleverly following [SE0269](https://github.com/apple/swift-evolution/blob/main/proposals/0269-implicit-self-explicit-capture.md).

```swift
button.tapHandler = { [weak self] in
    guard let self else { return }

    execute {
        // error: call to method 'method' in closure requires 
        // explicit use of 'self' to make capture semantics explicit
        dismiss()
    }
}

```

If you follow the rule – capture `self` as weak then unwrap and use it implicitly – compiler assists you to determine if `self` has to be captured again in inner closures.

\* [Michael Tsai - Blog - Weak Self: Closure Rules of Thumb](https://mjtsai.com/blog/2022/05/18/weak-self-closure-rules-of-thumb/)  
\* [Weak Self -- Closure Rules of Thumb • Christian Tietze](https://christiantietze.de/posts/2022/05/weak-self-consistency/)

* * *

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

Definitely. It feels very natural to have this.

> 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 wanted this since its pitch along with [SE-0345](https://github.com/apple/swift-evolution/blob/main/proposals/0345-if-let-shorthand.md): [Allow implicit `self` for `weak self` captures, after `self` is unwrapped](https://forums.swift.org/t/allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/54262)

And thank you for the proposal!

---

<div class="post-metadata">

**Author:** ![andrews05](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrews05/32/13816_2.png) [@andrews05](https://forums.swift.org/u/andrews05)\
**Post date:** [July 18, 2022, 6:51pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/5 "2022-07-18T18:51:06Z")

</div>

This is great and definitely worth a +1, though I personally would love to see it go a step further and add some way of eliding the `guard let self else { return }` line, which is almost always used when capturing weak self.  
Not sure what it might look like exactly, maybe `[self?]`, but the idea would be it would automatically return void if self is nil. I guess would only work for closures that return void, but I think that generally is the case.

---

<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:** [July 18, 2022, 6:54pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/6 "2022-07-18T18:54:15Z")

</div>

> [@andrews05](#):
>
> Not sure what it might look like exactly, maybe `[self?]`, but the idea would be it would automatically return void if self is nil. I guess would only work for closures that return void, but I think that generally is the case.

Let's keep this discussion focused on reviewing the proposal at hand; there is an extensive archive regarding the design space for unwrapping `self`, but it is not the topic of this proposal.

---

<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:** [July 18, 2022, 6:56pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/7 "2022-07-18T18:56:17Z")

</div>

There was a [pitch](https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805) from last August to do that using a syntax like `[guard self]` or `[weak(guard) self]`. The Core Team [weighed in](https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805/81) with this feedback:

> [@\`guard\` capture specifier for closure capture lists](https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805/81):
>
> The core team talked about this, and we're reluctant to add features that introduce new sources of control flow unless they significantly improve expressive power.

The idea for this proposal to allow implicit self in `weak self` closures did [spin off](https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805/82) from that thread though :)

---

<div class="post-metadata">

**Author:** ![andrews05](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrews05/32/13816_2.png) [@andrews05](https://forums.swift.org/u/andrews05)\
**Post date:** [July 18, 2022, 7:07pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/8 "2022-07-18T19:07:28Z")

</div>

Oops, sorry for not doing my homework. Thanks for the link though, it was good to read through that.

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [July 18, 2022, 8:06pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/9 "2022-07-18T20:06:09Z")

</div>

This seems a natural extension of the elisions for `self.` already present in the language.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [July 19, 2022, 9:02am UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/10 "2022-07-19T09:02:50Z")

</div>

Personally I feel self in general should not be elided, point of ensuring there are no implicit reference cycles is one of the ones, but for me it is for readability overall over the cost of a few key presses.

Better for autocompletion (finding the method you want, no global function to list even if you start with self.), better for readability in Pull Requests outside of the editor too (one of the reason argument labels are so useful, if we were always stuck on our IDE’s with smart suggestions/overlays we would need labels in code less as the IDE would remind us what they are supposed to be which is maybe one of the reasons why Kotlin did not make them mandatory for new code).

In the ideal world everything is decomposed to small objects, few vars, and all… but in a lot of code I see the “is this a local var or an instance var” is a question that would not even be there with self, but 🤷‍♂️. There was a Polychromatic extension for Xcode in the Alcatraz days that would color the vars that we’re in the same scope / related… it helped me sooo soo much in having all kinds of code more readable.

---

<div class="post-metadata">

**Author:** ![pronebird](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pronebird/32/21721_2.png) [@pronebird](https://forums.swift.org/u/pronebird)\
**Post date:** [July 19, 2022, 11:51am UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/11 "2022-07-19T11:51:04Z")

</div>

Implicit self is all rage in Swift community and I can see how this can implode into the faces of many engineers mistakenly referencing a shadowed variable. It already implodes elsewhere anyway right? That's said I am all in on this suggestion. The code is nice without explicit `self`.

---

<div class="post-metadata">

**Author:** ![morisk](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/morisk/32/2045_2.png) [@morisk](https://forums.swift.org/u/morisk)\
**Post date:** [July 20, 2022, 6:50am UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/12 "2022-07-20T06:50:58Z")

</div>

Yes!  
+1

Please more of these.

---

<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:** [July 20, 2022, 8:57pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/13 "2022-07-20T20:57:48Z")

</div>

After a quick read, I am +1 on the proposal.

I have two pieces of feedback on the proposal itself. The examples in the proposal use `guard let` exclusively although the proposal title says it is for any unwrapped `self`.

Possibly add at least one example to the proposal that shows this with `if let` and possibly a sentence that explicitly mentions all of the unwrapping mechanisms this will be used with.

I mention it because the evolution proposal is often the most detailed documentation available for any given language feature.

Also, I think there's a typo in the _Detailed design_ section:

> Following the precedent of SE-0269, additional closures nested inside the `[weak self]` closure _most_ capture `self` explicitly

I believe _most_ should be _must_.

---

<div class="post-metadata">

**Author:** ![Ian\_Keen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ian_keen/32/18492_2.png) [@Ian\_Keen](https://forums.swift.org/u/Ian_Keen)\
**Post date:** [July 21, 2022, 8:55pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/14 "2022-07-21T20:55:17Z")

</div>

I tend to agree. Too often 'less code' is confused with 'clean code', less doesn't always mean clean. In fact being more explicit is often cleaner IMO. This strikes me as yet another proposal geared towards attempting to improve code writability, rather than readability.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [July 21, 2022, 10:15pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/15 "2022-07-21T22:15:31Z")

</div>

I think it’s reasonable to dislike implicit access to `self`. (I may not agree with you, but it’s an understandable argument.) However, Swift does allow these accesses in many situations today, situations much more prominent than those in the proposal. Given that, I think the argument that implicit accesses are bad _in general_ does not justify restricting them _only in these situations_; the remedy does not suit the diagnosis. You can argue that implicit accesses should be removed in general; you are unlikely to prevail, but you can argue it. Otherwise, I think you need to find a more specific argument why they’re especially bad in the situations in the proposal and therefore we should keep the current rule.

---

<div class="post-metadata">

**Author:** ![allenh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allenh/32/19965_2.png) [@allenh](https://forums.swift.org/u/allenh)\
**Post date:** [July 22, 2022, 4:13am UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/16 "2022-07-22T04:13:17Z")

</div>

I am +1

One of my earliest memories writing Swift was some frustration over moving code with implicit self into closures and immediately having to go through the lines and prefix all my lines with `self.`. `self` being completely required inside closures was a double-edged sword in this way, and it seems like this change really will smooth out that sharp edge.

All the other comments about whether or not eliding self should be allowed really seems like a code style question to be chosen by teams and enforced by formatters.

---

<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:** [July 22, 2022, 11:21am UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/17 "2022-07-22T11:21:47Z")

</div>

> [@allenh](#):
>
> One of my earliest memories writing Swift was some frustration over moving code with implicit self into closures and immediately having to go through the lines and prefix all my lines with `self.`

You never had to: you could have put `self` in the capture list and have the code unchanged.

+1 on the pitch, it is very natural and allows the same convenience for weak self capture as we had for strong self capture.

Is only the short `quard let self else ...` form supported for this feature or `guard let self = self else ...` supported as well? No strong opinion, if it is simpler to support only the first form it's fine (and will also motivate users towards using the short form.

---

<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:** [July 22, 2022, 1:07pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/18 "2022-07-22T13:07:34Z")

</div>

> [@tera](#):
>
> Is only the short `quard let self else ...` form supported for this feature or `guard let self = self else ...` supported as well?

All forms of optional unwrapping would be supported, including `if let self`. The only requirement in the implementation is that the type of `self` is non-optional.

---

<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:** [July 22, 2022, 3:26pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/19 "2022-07-22T15:26:09Z")

</div>

Please confirm:

This will be supported (as you've just said):

```
guard let self else { ... }
property = 1 // without self. prefix

if let self {
    property = 1 // without self. prefix
}

```

My question was about the following, will it be supported?

```
guard let self = self else { ... }
property = 1 // without self. prefix

if let self = self {
    property = 1 // without self. prefix
}

```

And (I hope) this won't be supported:

```
guard let self = anotherVar else { ... }
property = 1 // Error

if let self = anotherVar {
    property = 1 // Error
}

```

---

<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:** [July 22, 2022, 3:28pm UTC](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040/20 "2022-07-22T15:28:31Z")

</div>

> [@tera](#):
>
> My question was about the following, will it be supported?
> 
> ```swift
> guard let self = self else { ... }
> property = 1 // without self. prefix
> 
> if let self = self {
> property = 1 // without self. prefix
> }
> 
> ```

Yes this is fine as well 👍🏻

> [@tera](#):
>
> And (I hope) this won't be supported:
> 
> ```swift
> guard let self = anotherVar else { ... }
> property = 1 // Error
> 
> if let self = anotherVar {
> property = 1 // Error
> }
> 
> ```

This is disallowed.

[Next page](https://forums.swift.org/t/se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59040.md?page=2)