[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