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

[Taras Zakharko]

-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