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

[Shawn Erickson]

Kurt curious... the "[unowed self]? in" style... is that part of another
proposal? The one I hit on is talking about using "[guard self] in".

On Fri, Feb 19, 2016 at 3:08 PM Shawn Erickson <shawnce at gmail.com> wrote:

> 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/7a75c631/attachment.html>