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

Erica Sadun erica at ericasadun.com
Fri Feb 12 16:48:10 CST 2016


Oh, and I just realized I have been responding to the wrong thread.


[weak self]
guard reconstitute self else { return }

I thought it might be handy to control how the guard exits scope, enabling self == nil (as well as any other reconstitutions of a weak variable) failure cases to do reporting, fatalError-ing, etc. I think it's important to defer to the programmer on how the weak self condition is handled, enabling any clean-up action to be taken as well as deciding whether to terminate the app, recover, etc.

-- E, off to pick up kids



> On Feb 12, 2016, at 3:46 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> Alternatives Considered
>> 
>> Status Quo
>> 
>> Closures with an Optional Return Type
>> 
>> Closures with a Bool Return Type
>> 
>> Closures with Arbitrary Return Types
> 
> I would also discuss the alternative of allowing `self` to be shadowed so that you could write `guard let self = self else { return }`. Your proposal still has some advantages over that one, but I would like to see those explicitly called out and discussed.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/2aef42c4/attachment.html>


More information about the swift-evolution mailing list