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

[Shawn Erickson]

I get that :) but I think it would be helpful to go beyond the no-op case
and help solve the "strongify" situation that exists in the larger problem
domain.

The "strongify" issue – to me – is mostly about avoiding the need to rename
the captured var in the block to allow for the reference to become a strong
reference. I feel it would be great to tackle that for more then the no-op
case.

In my experience I have had what once was "a simple no-op on nil case" turn
into "if nil do some book keeping and no-op the rest" often enough to
desire a broader solution.

On Fri, Feb 19, 2016 at 2:03 PM Kurt Werle <kurt at circlew.org> wrote:

> On Fri, Feb 19, 2016 at 1:39 PM, Shawn Erickson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> 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.
>>
>
> That's the beauty of it.  If you want to do something else, this isn't
> what you want.  This is just a simple bit of sugar to get rid of the very
> common use case where you have a nilable/void callback that you only want
> executed if self is not nil.
>
> If you want/need to do something more complicated, then
> { [unowned self] in
>   guard self != nil else {
>     Do the other thing
>   }
> }
> is great.  It's not boilerplate because you're doing something useful in
> the else case.
>
> I do still prefer the [unowned self]? syntax, though.  It feels so similar
> to object?.doSomething().  If the lvalue is nil, you get nothing!
>
> Kurt
> --
> kurt at CircleW.org
> http://www.CircleW.org/kurt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/dcda8eb1/attachment.html>