[swift-evolution] Proposal: Allow `[strong self]` capture in closures and remove the `self` requirement therein

[ilya]

+1 explicit is better than implicit (capture of self)

This should also be promoted by style guides. It's easy for a novice to
miss that self.property captures the whole self, the capture list is much
more useful in that regard.

On Wed, Dec 16, 2015 at 05:06 Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

> I believe it has been made clear upthread now, but only the closure is
> capturing self.  Your evil function only stores a copy of the dictionary.
>
> This behavior is identical whether you use [strong self] and metadata or
> you use self.metadata so I don’t understand why it would be an argument
> against the proposal.  Either way the capture of self by the closure is
> explicitly represented in the code where it happens.  [strong self]
> actually seems a bit more clear to me.
>
> An example that behaves like you stated could be concocted if we modify
> your example to pass a bound method rather than a property value, however
> that seems pretty unlikely to happen unintentionally even if / when we can
> obtain references to bound property getters / setters.
>
> typealias evilArg = [String:String]
> var strongReference: () -> evilArg
> func evil(foo: () -> evilArg ) {
>     strongReference = foo
> }
>
> final class Photo {
>     var data = [UInt8](count: 100000000, repeatedValue: 0) //a large
> amount of data
>     func metadata() -> [String: String] { return [:] }
>
>     func save() {
>         dispatch_async(dispatch_get_global_queue(QOS_CLASS_DEFAULT, 0)) {
>             evil(self.metadata)
>         }
>     }
> }
>
> I understand why you’re afraid of anything that might lead to
> unintentionally storing a strong reference or creating a reference cycle.
> I don’t understand why this proposal is likely to make that happen.  I
> would even argue it might make it less likely to happen.  If developers get
> in the habit of using the capture list rather than explicitly using “self.”
> in the body they will be more likely to capture only what they need.  In
> your example the developer may have specified [metadata = self.metadata]
> rather than using [strong self] if the metadata value at the time of
> closure capture was sufficient.
>
> Matthew
>
>
>
> On Dec 15, 2015, at 7:23 PM, Drew Crawford via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 15, 2015, at 7:15 PM, Greg Parker <gparker at apple.com> wrote:
>
> We could make it more difficult for unaware programmers to *write* the
> `[strong self]` version, at least. When a programmer writes just `metadata`
> in a closure, the compiler could continue to suggest using `self.metadata`
> and not suggest using `[strong self]`.
>
>
> That's not (especially) the danger I'm worried about.
>
> I'm worried about the case where I write `[strong self] in` and then years
> later I add the `evil(f)` to the bottom of the closure, because it turns
> out we need more code in there.
>
> I'm also worried about the case where I write nonEvil(f) but at some later
> time the implementation of nonEvil(f) becomes evil.
>
> I'm also worried about the case where nonEvil(f) is a call into
> closed-source UIKit and without any visibility to me, UIKit's
> implementation of nonEvil becomes evil between iOS10b3 and iOS10b4.
>
> These things are "category 5" bugs waiting to happen, and they can't be
> competently addressed with a UI-level fix in Xcode.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20151216/6d2a0a11/attachment.html>