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

[Shawn Erickson]

I am talking about when capturing weak. The unowned capture situation is
the simpler variant of weak, one that doesn't happen to exhibit the
gyration of strongifying a weak capture.

In the weak situation you most often want to promote the captured weak
reference to a strong reference for some scope of code. You have to do this
currently by assigning the one or more captured weak references you have to
a differently named strong reference.

Additionally it isn't clear to me how a block with multiple captures would
play in what you are proposing.

If the strongify situation could be improved by allowing a captured weak
reference to be made strong while avoiding the renaming gyration then I
could see that being coupled with the "[weak/unowned foo]? in" no-op case
(assuming folks see enough reason for the no-op case).

-Shawn

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

> And to follow up on my own email, isn't that exactly the flow you want?
>
> First you do
> { [unowned self]? in
>   ...
> }
>
> Then you realize that you need to deal with the else case.  You nuke the ?
> and add a guard.
> { [unowned self] in
>   guard if unowned self != nil self {
>     ...
>
> I mean -- I look at that and it seems clear and easy.  You have the ? to
> deal with the nil case.  You remove it and add the block to deal with the
> special nil case.  The intention of both seems clear.  You added the guard
> code when you needed it.
>
> Sign me up!
> Kurt
>
> On Fri, Feb 19, 2016 at 2:39 PM, Kurt Werle <kurt at circlew.org> wrote:
>
>>
>>
>> On Fri, Feb 19, 2016 at 2:30 PM, Shawn Erickson <shawnce at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>>>
>> OK - so what's wrong with:
>>
>>
>>> { [unowned self] in
>>>>   guard self != nil else {
>>>>     Do the other thing
>>>>   }
>>>> }
>>>>
>>>
>> It's basically what you're asking for - an unowned implicitly unwrapped
>> variable followed by an else statement that takes care of the nil case.
>> Right?
>>
>> Kurt
>> --
>> kurt at CircleW.org
>> http://www.CircleW.org/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/9a0a0f2f/attachment.html>