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

[Kurt Werle]

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

> 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".
>

Kenny Leung originally suggested instead of [guard self] (or my earlier
notion of [firm self]) that it be [unowned/weak self]? - which more closely
resembles the intent of object?.method() in that it does exactly the same
kind of thing - whereas [guard self] implies guard, which implies an else
statement and more complexity.

The drawback - as you have pointed out - is what to do with multiple
parameters
[unowned self, some, others]?
What does that do?  My (Kenny's) notion is that it implicitly does
if let self = self, some = some, others = others {
  ...
}

What if you want some tricky combination of strong/weak references in that
block that you want to handle, where some may be nil and others not?  Yeah,
this would not work for that.  But I can count the number of times where I
wanted complex references in a [parameter block] where I did not have to
handle them with various guards/if let's using no hands.  Which is to say,
this proposal is specifically for the very common boiler plate where you
want everything not to be nil, you don't want to explicitly unwrap it with
boiler plate code, and you want nothing to happen if something is nil.

While I like the look of [unowned self]? better than [guard self], I'd be
happy enough with either.

Kurt


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/
>>>
>>


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