[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 17:41:00 CST 2016
I'd be fine with let self = self. My biggest issue with [guard self] is that it has to happen before any defer.
-- E
> On Feb 12, 2016, at 4:07 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>
>> guard reconstitute self else { return }
>
> I think `reconstitute` is inferior to `let self = ` on almost every axis. It's longer, requires you to learn a new keyword instead of applying existing constructs, and doesn't solve any other problems the way permitting `self` shadowing would.
>
>> 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.
>
> I'm really not convinced by this by this. If you want to terminate, capture the variable `unowned`. If you want to customize the behavior in some other way, do a weak-strong dance just like today.
>
> I'm not entirely convinced `[guard]` is a good idea either, but the lack of `else` customization isn't the reason for my concern. "Just do nothing if this doesn't exist" is by far the most common case for guarding on a weak `self`.
>
> --
> Brent Royal-Gordon
> Architechies
>
More information about the swift-evolution
mailing list