Pitch: Weak method storage modifiers (aka weak references)

[DevAndArtist (Adrian Meister)]

This is not an entirely new pitch, because I already pitched it a while ago but never pursued it that much after @anandabits pointed me at his proposal that needs some revisiting.

I initially asked about that on Twitter:

https://twitter.com/DevAndArtist/status/873241946483040256

Then there is this thread converted from the mailing list:

[Pitch] Introduction of `weak/unowned` closures

Hello Evolution, I’d like to pitch a new idea and see where it would go. Recently I tapped into a small trap and just now realized that even that non-escaping should have been the default for closures (SE–0103) there is an exception for that. Apparently generics don’t follow that rule and a closure like Optional<() -> Void> or simply (() -> Void)? is still escaping by default. But that was the half of the story yet. As we all know and “love” reference lists inside closures, methods don’t have…

---

I've been bitten by this issue too so I know how it feels like, and this is exactly why I don't like the implicit @escaping in generic context (Optional is just one of them). My pitch was all about invalidating a weak closure when the captured reference are no longer available or use the unowned closure on own risk with an assumption that it will not fail. At the same time it would avoid retain-cycles.