[swift-evolution] [Proposal Update 1] A simplified notation for avoiding the weak/strong dance with closure capture lists

David Hart david at hartbit.com
Sun Feb 14 09:31:07 CST 2016


-1

Like was previously stated, I would prefer something like "guard let self = self else {}" to be valid.
It has the benefit of:

- being less surprising
- having an even smaller language footprint
- fixing all the caveats of the original proposal

> On 13 Feb 2016, at 22:27, Carlos Parada via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> guard self  = self else {} 
> 
> I agree with Taras on this. I also would prefer something along these lines. Besides being more consistent and familiar, the else clause encourages you to think what would happen if self is gone. "Is it fine if I just return or do I have to display an error message?” This helps lessens the points Javier Soto had against the original idea.
> 
> — Carlos Parada
> 
> 
>> On Feb 13, 2016, at 3:07 AM, Taras Zakharko via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> -1
>> 
>> I like the concept but the proposed solution is inflexible and way too specific. Inability to deal with return values and also inability to execute behaviour if the references have led the scope are big no-goes IMO. This is adding more arbitrary magic to the language and making it more complex. 
>> 
>> I am still favouring the 
>> 
>> guard self  = self else {} 
>> 
>> solution. Slightly more verbose, but infinitely more flexible and makes it very clear what is going on. 
>> 
>> — Taras
>> 
>>> On 13 Feb 2016, at 10:46, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> I think "return and do anything if self is nil" is a code-smell in many cases. You're preventing a crash and a retain cycle, but at the expense of potentially leaving some piece of functionality broken.
>>> 
>>> You're breaking something unless you're not breaking anything. And I think it's actually pretty common that you're not breaking anything. For instance, if you perform an async network call to fetch the contents of a view controller and then dismiss the view controller before the fetch is complete, throwing away the results is often the best you can do. Even if you get an error, that error is probably no longer relevant.
>>> 
>>> Certainly not all blocks are like this—if you're *writing* data, you wouldn't want to throw away the result. But I think completion handlers which really can be safely ignored if the object that scheduled them has gone away are pretty common. Maybe not common enough to justify such a dramatic shorthand, but certainly common enough that I wouldn't call it a smell.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list