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

[Javier Soto]

-1

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. I think often
strongly capturing self is OK if one can reason that the closure won't live
forever, or use unowned if self is guaranteed to outlive the closure.
Always resorting to weak self by default and without considering whether
it's the right choice means not thinking carefully about the lifetime
semantics of the code that you're writing, and adding syntax to make that
easier would just encourage that.
On Fri, Feb 12, 2016 at 3:41 PM Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160213/e29c8901/attachment.html>