[swift-evolution] [Proposal] Allow upgrading weak self to strong self by assignment

Shawn Erickson shawnce at gmail.com
Fri Feb 19 15:39:13 CST 2016


I also like this proposal. I wish we could go further in removing the
boilerplate but then you have to start to consider usage scenarios that you
would lose in the process.

For example [guard self] capture option supports one specific situation
without the ability of the block to take alternate actions in the situation
of weak self being nil and also requiring no return blocks. This is great
obviously for that particular situation however it doesn't really help with
the other situations.

This proposal allows for a wide range of possibilities in a language
natural way while reducing the code gyrations we currently do.


On Fri, Feb 19, 2016 at 12:21 PM Taras Zakharko via swift-evolution <
swift-evolution at swift.org> wrote:

> Very much in favor of this solution (removing the standalone let self =
> self!). Its does not introduce any new syntax, its semantics is very
> obvious, its explicit, and its also much more flexible than the alternative
> guard capture list proposal while keeping magic to the necessary minimum.
>
> — Taras
>
>
> On 19 Feb 2016, at 20:40, Evan Maloney via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Feb 19, 2016, at 2:30 PM, plx via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> networkRequest.fetchData() { [weak self] result in
>     guard self != nil else { return }
>
>     let self = self!
>
> …isn’t there a race condition in this example (admittedly an *unlikely*
> one in most settings, but still…)?
>
>
> Yes, that's a good point.
>
> Now that I think about it, allowing a standalone `let self =` could never
> be implemented in a way *guaranteed* to avoid a race condition, so perhaps
> I should remove it from the proposal altogether.
>
> When I incorporate the next round of feedback, I'll rework the proposal to
> indicate that it can only be used with `if let` or `guard let`.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/cad60e76/attachment.html>


More information about the swift-evolution mailing list