# Pitch: Weak method storage modifiers (aka weak references)

**URL:** <https://forums.swift.org/t/pitch-weak-method-storage-modifiers-aka-weak-references/12161>\
**Category:** Pitches\
**Created:** [April 26, 2018, 2:58am UTC](https://forums.swift.org/t/pitch-weak-method-storage-modifiers-aka-weak-references/12161 "2018-04-26T02:58:12Z")\
**Posts on this page:** 1\
**Showing post:** 16

<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:** [May 2, 2018, 4:20pm UTC](https://forums.swift.org/t/pitch-weak-method-storage-modifiers-aka-weak-references/12161/16 "2018-05-02T16:20:21Z")

</div>

> [@Chris\_Lattner3](#):
>
> I haven’t thought deeply about this, but my off-the-cuff behavior is that a weak reference to a closure leads to weak references to any closed-over state (e.g. the self argument of a method). The closure would be deallocated if any of the closed over state is deallocated.

Interesting. It seems to me like this approach might lead to confusion about the behavior of capture specifiers because it allows a library to effectively turn every capture into a weak capture. For example, somebody might write a type that exposes an `addObserver(_ observer: @escaping (Event) -> Void)` method and stores the closures with weak references with the idea that users won't need to specify `weak self`.

If this style of API became common people may begin to think less about how they capture objects. It also introduces the need for libraries to document how they store closures and for users to be aware of the semantics the library uses. It would probably lead to requests to introduce a `reallyStrong` capture specifier (name intentionally awkward) that is strong even in the presence of a weak reference to the closure.

I gave some thought to this problem space last year and was heading in the direction of introducing [guarded closures](https://forums.swift.org/t/draft-guarded-closures-and-guarded-arguments/5251). I was working on a second draft incorporating some of the feedback from that thread when I decided to set it aside. This design makes capture semantics clear at the declaration site of the closure but supports an "inverted" default that is sugar for closures that (mostly) capture `weak` with a `guard` on the weak captures at the beginning of the closure. It also allows an API to "invert" the default by using `@guarded` instead of `@escaping`, requiring users to provide a guarded closure. Users would still be able to use explicit `strong` captures where necessary.

I recently started a [new thread for guarded closures](https://forums.swift.org/t/guarded-closures/11029) when the topic came up in [The Future Of [weak self] Rebinding](https://forums.swift.org/t/the-future-of-weak-self-rebinding/10846/22). It's clear that there is a lot of interest in doing _something_ in this area. It's less clear what the right balance is. 🙂

---

_[View the full topic](https://forums.swift.org/t/pitch-weak-method-storage-modifiers-aka-weak-references/12161)._