# SE-0269: Increase availability of implicit  self  in  @escaping closures when reference cycles are unlikely to occur

**URL:** <https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376>\
**Category:** Proposal Reviews\
**Created:** [October 31, 2019, 9:57pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376 "2019-10-31T21:57:58Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![tkremenek](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tkremenek/32/9115_2.png) [@tkremenek](https://forums.swift.org/u/tkremenek)\
**Post date:** [October 31, 2019, 9:57pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/1 "2019-10-31T21:57:58Z")

</div>

The review of [SE-0269: Increase availability of implicit `self` in `@escaping` closures when reference cycles are unlikely to occur](https://github.com/apple/swift-evolution/blob/master/proposals/0269-implicit-self-explicit-capture.md) begins now and runs through November 12, 2019.

The proposal is written by @Jumhyn.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via [email](mailto:kremenek@apple.com) or direct message on the forums. If you send me email, please put "SE-0269" somewhere in the subject line.

**What goes into a review of a proposal?**

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

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

Thank you for contributing to Swift!

Ted Kremenek  
Review Manager

---

<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:** [October 31, 2019, 10:35pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/2 "2019-10-31T22:35:03Z")

</div>

Would we be able to expand it to include the case where `weak self` is rebound to strong `self`?

```swift
execute { [weak self] in
  guard let self = self else { ... }

  // here
}

```

---

<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:** [October 31, 2019, 10:44pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/3 "2019-10-31T22:44:47Z")

</div>

I think that would be a reasonable extension of this idea, but IMO it would require some more careful design consideration. E.g., would implicit `self` be available inside an `if let self = self` block, or only when `self` is re-bound at the top level? What if you just did `let self = self!`? I think adding a section about more general `self` rebinding to **Future Directions** would be a good idea, though—I’ll do that.

---

<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:** [October 31, 2019, 11:23pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/4 "2019-10-31T23:23:25Z")

</div>

This is great! I appreciate the thought given to all of the edge cases here.

I'd personally like to see the existing fix-it eliminated as part of this proposal as suggested in the alternatives considered section. Including both the old and new fix-its could get noisy, and imo it would be good to push this new style of signaling self capture as the preferred option.

---

<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:** [October 31, 2019, 11:31pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/5 "2019-10-31T23:31:33Z")

</div>

> when reference cycles are **unlikely** to occur

Is it possible to create reference cycle with value-type?

---

<div class="post-metadata">

**Author:** ![GetSwifty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/getswifty/32/39108_2.png) [@GetSwifty](https://forums.swift.org/u/GetSwifty)\
**Post date:** [October 31, 2019, 11:31pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/6 "2019-10-31T23:31:52Z")

</div>

+1

I'm a strong proponent for simplifying syntax for @escaping closures. IMO there's still room for improvement there, but I haven't seen a clearly "right" solution.

This proposal removed a redundancy pain point with no syntax changes or additions to the language. Complete win in my book!

---

<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:** [October 31, 2019, 11:39pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/7 "2019-10-31T23:39:45Z")

</div>

> [@Lantua](#):
>
> Is it possible to create reference cycle with value-type?

If the value type contains references, then yes!

---

<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:** [October 31, 2019, 11:47pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/8 "2019-10-31T23:47:17Z")

</div>

I see. Still, in that case value-type in capture list still wouldn't help fixing that, would it?

Guess my ultimate question is, _what is the scenario one would want to put value-type in capture list?_. Since that would be what interfere with the latter part of the proposal.

---

<div class="post-metadata">

**Author:** ![QuinceyMorris](https://avatars.discourse-cdn.com/v4/letter/q/d26b3c/32.png) [@QuinceyMorris](https://forums.swift.org/u/QuinceyMorris)\
**Post date:** [November 1, 2019, 3:31am UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/9 "2019-11-01T03:31:01Z")

</div>

SE-0269: Yes, please.

---

<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:** [November 1, 2019, 7:53am UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/10 "2019-11-01T07:53:02Z")

</div>

> [@jarod](#):
>
> I'd personally like to see the existing fix-it eliminated as part of this proposal as suggested in the alternatives considered section. Including both the old and new fix-its could get noisy, and imo it would be good to push this new style of signaling self capture as the preferred option.

I think that declaring capture list as the preferred option need more discussion.  
I don't see it as a win for simple closures.

```swift
foo { self.bar() }

```

vs

```swift
foo { [self] in
  bar()
}

```

---

<div class="post-metadata">

**Author:** ![technicated](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/technicated/32/5420_2.png) [@technicated](https://forums.swift.org/u/technicated)\
**Post date:** [November 1, 2019, 8:09am UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/11 "2019-11-01T08:09:09Z")

</div>

+1 and maybe suggest `self.` as a fixit only for single-expression closures instead of `[self] in`?

---

<div class="post-metadata">

**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\
**Post date:** [November 1, 2019, 10:11am UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/12 "2019-11-01T10:11:50Z")

</div>

So I dislike this, but only because I dislike implicit `self`. I am aware that my dislike of implicit `self` puts me in a minority of the Swift community, but regardless, I would rather not see it further propagated. I have no particular problem with any of the rest of the pitch, so if the consensus of the community is that implicit `self` is great then I won’t try to stand in the way.

---

<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:** [November 1, 2019, 11:17am UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/13 "2019-11-01T11:17:07Z")

</div>

I’m not sure that “single expression” is necessarily the best heuristic, since you could have something like

```swift
foo {
    bar(with: thing1, and: thing2)
}

```

Where the suggested fix-it would be:

```swift
foo {
    self.bar(with: self.thing1, and: self.thing2)
}

```

Perhaps “single use of implicit `self`” would be a better test, but I’d still rather introduce both with this proposal and see a follow-up proposal/bugfix that improves the diagnostic logic.

---

<div class="post-metadata">

**Author:** ![paiv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/paiv/32/4041_2.png) [@paiv](https://forums.swift.org/u/paiv)\
**Post date:** [November 1, 2019, 1:38pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/14 "2019-11-01T13:38:16Z")

</div>

Yes to the proposal. This would eliminate unexpected `self.` pollution of code that would otherwise be written without `self.` when outside escaping closures. Which was an annoyance from the first days of Swift.

Thank you @Jumhyn for the thought and work put into this.

* * *

Side note to future proposals: this one originated from the observation that "explicit capture semantics" is not explicit. `self.foo()` have no indicators whether `self` is captured or not – you need to know its context. This leads to a) pollution with unexpected `self.` to silence compiler errors; b) no support for projects adopting `self.` on every member access.

---

<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:** [November 1, 2019, 2:06pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/15 "2019-11-01T14:06:40Z")

</div>

FWIW, @lukasa, I have in the past felt similarly about implicit `self`, but part of that was precisely because of the annoyance addressed by this proposal—highly event-driven codebases which wanted to use implicit `self` could only do so inconsistently (which I made a note of in the proposal).

That said, even if one takes a principled stand against the use of implicit `self`, I don't think that enforcing arbitrary restrictions on its use makes for good language design. E.g. even if I hypothetically felt like "Eliminate implicit `self`" were a worthwhile proposal, I probably wouldn't support a proposal of the form "Eliminate implicit self for property references, but not method references" solely based on the argument that it came closer to my ideal. So though I'm sympathetic to concerns about the use of implicit `self`, I think that those concerns are somewhat orthogonal to increasing the consistency and simplicity of the rules surrounding implicit `self` (and probably better enforced by a style guide/linter).

---

<div class="post-metadata">

**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\
**Post date:** [November 1, 2019, 2:20pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/16 "2019-11-01T14:20:43Z")

</div>

To be clear, I agree that partial removal of implicit self is not sensible: it should be acceptable broadly or not at all. My objection (which I hope was clearly a very _weak_ objection) was only that expanding the availability of implicit self is moving the curve in the opposite direction of my preferred one. 😁

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [November 1, 2019, 5:47pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/17 "2019-11-01T17:47:34Z")

</div>

I am neutral on this because the current behavior is simple enough to explain. Introducing nuance here doesn't seem like a huge win.

---

<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:** [November 1, 2019, 6:16pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/18 "2019-11-01T18:16:16Z")

</div>

I'd still use the capture list in that example for consistency even though it's more characters, but it's definitely a subjective thing.

---

<div class="post-metadata">

**Author:** ![GetSwifty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/getswifty/32/39108_2.png) [@GetSwifty](https://forums.swift.org/u/GetSwifty)\
**Post date:** [November 1, 2019, 6:36pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/19 "2019-11-01T18:36:09Z")

</div>

FWIW I think I agree. IMO a capture list is a much better indication to (especially new) users that _something different_ is happening here. The current Implicit `self` capture feels like an odd compiler constraint that means "oh I guess I have to use self here for some reason".

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [November 4, 2019, 5:39pm UTC](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/20 "2019-11-04T17:39:58Z")

</div>

- What is your evaluation of the proposal?

I'm neutral on the first part of the proposal as proposed. It's reasonable in the cases where it works. But there isn't an obvious way to support weak captures so it doesn't replace the current syntax either.

I have some concerns about the second part of the proposal. If it could be limited to value semantics it would make sense to me. But it can't, it is possible to store references in a value type, therefore making reference cycles possible without any explicit indication of the capture.

If the first part of the proposal is accepted value types would already be able to explicitly capture `[self]` rather than writing `self.` everywhere. This might be enough sugar for this use case and does not have the potential to introduce cycles without indication of the capture. It also significantly strengthens the argument for accepting the first part of the proposal _if the second part is left off_, as it significantly widens the use cases for the first part fo the proposal.

Overall, I think this proposal is a tough judgement call. I don't have a firm opinion, but my instinct is that we might be better off if only one part is accepted. Having either one in the language weakens the motivation for the other IMO. On balance, I think the first part of the proposal has the strongest motivation.

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

Possibly? I trust the core team to decide on this.

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

IMO, the first part fits better than the second.

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

A quick read, followed by consideration of the tradeoffs involved.

[Next page](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376.md?page=2)