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

[Andrew Bennett]

A quick note, I'm not sure if it's a hack but you can probably still do
this:

   guard let `self` = self else { return }

It would be good to support this without backticks, I suppose it would be
very special case though. I wonder if you could reassign self as a
different type...


Andrew Bennett

On Saturday, 20 February 2016, Kurt Werle via swift-evolution <
swift-evolution at swift.org> wrote:

> On Fri, Feb 19, 2016 at 3:12 PM, Shawn Erickson <shawnce at gmail.com
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','kurt at circlew.org');>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:30 PM, Shawn Erickson <shawnce at gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','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/20160220/6e9e425d/attachment.html>