<div style="white-space:pre-wrap">+1 explicit is better than implicit (capture of self) <br><br>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. <br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 05:06 Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div></div></div><div style="word-wrap:break-word"><div><div><span style="font-family:HelveticaNeue">typealias evilArg = [String:String]</span></div></div></div><div style="word-wrap:break-word"><div><div>var strongReference: () -> evilArg<br>func evil(foo: () -> evilArg ) {<br> strongReference = foo<br><div><div style="word-wrap:break-word"><div>}</div><div><br></div><div></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div style="word-wrap:break-word"><div>final class Photo {<br> var data = [UInt8](count: 100000000, repeatedValue: 0) //a large amount of data<br></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div style="word-wrap:break-word"><div> func metadata() -> [String: String] { return [:] }</div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div style="word-wrap:break-word"><div><br> func save() {<br> dispatch_async(dispatch_get_global_queue(QOS_CLASS_DEFAULT, 0)) {<br> evil(self.metadata)<br> }<br> }<br><div><div style="word-wrap:break-word"><div>}</div></div></div></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div style="word-wrap:break-word"><div></div></div></div></div></div><div><br></div><div>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.</div></div><div style="word-wrap:break-word"><div><br></div><div>Matthew</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><br><div><blockquote type="cite"><div>On Dec 15, 2015, at 7:23 PM, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Dec 15, 2015, at 7:15 PM, Greg Parker <<a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a>> wrote:</div><br><div><span style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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]`.</span></div></blockquote></div><br><div>That's not (especially) the danger I'm worried about.</div><div><br></div><div>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.</div><div><br></div><div>I'm also worried about the case where I write nonEvil(f) but at some later time the implementation of nonEvil(f) becomes evil.</div><div><br></div><div>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.</div><div><br></div><div>These things are "category 5" bugs waiting to happen, and they can't be competently addressed with a UI-level fix in Xcode.</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAcWRvrKJiA0Q-2FRIpXY8-2B503kAOGN-2B9XG2PlniO9WFb2Q7QEqJVC04Bo5Ogu5HSavR-2FkXcnfJ3VP1CpB7uYILkfTQ3cMXUMYveFmskLKIiZg5A0eYsQvB-2BpT2i8593bus-2Fem0QOkd23pkhmoGsw4VPDpYAm1-2FrpPLdGAuw1cLJAaFIWCGpWuAW5HmC6vKdAL-2Fqs-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54MNh1VMcq1gEkchtcNCD0P6nwRqQoa6XUtMNu86XI5NbbNnXc78wbUX4Wvc5bNoy46TbNcQ0pBbxqTmypMComMFJujgXhYmoFthjkHEAK49a7agsoDy8HZGKCOd7wbSrz8iT4G0sjoae1JTJMOihnVPfXdkDUO1naTnuVkQu1iiX7-2BUKJrQadXl-2FSumnQ-2FcHK0-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>