<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yeah, hard to say how extreme it needs to be to justify this sort of change. Does running into unintentional retain cycles when using closures for event handlers *constantly* count as extreme? :)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">In a typical garbage collected language, using closures like this is common and a non-issue, but in Swift the ownership in these situations is something you have to actively think about which is a distraction when you want to spend your time thinking about what you're building instead. It reminds me of manual memory management (which of course it is).</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">l8r</div><div id="AppleMailSignature">Sean </div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Sep 28, 2016, at 7:48 PM, Jay Abbott <<a href="mailto:jay@abbott.me.uk">jay@abbott.me.uk</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Sean, yeah that's kind of what I was suggesting for @escaping closures - it should be the default... but it is a breaking change and as Chris pointed out that would need extreme justification... plus it would be a behaviour change with no syntax change, so code that was never "upgraded" would be very difficult to tell the original intention. I like the idea but I don't know if I can come up with "extreme justification" for it.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 29 Sep 2016 at 01:46 Sean Heber <<a href="mailto:sean@fifthace.com">sean@fifthace.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Now that I think about this, wouldn't that be a better default behavior? All captures are this "required" type which means all closures are typed as optional. To override that behavior, you'd have to explicitly declare a weak or unowned capture instead and if you did that for all reference captures, the closure's type would be non-optional as they are now. Seems like that'd be safer. I'll shut up now.</div></div><div dir="auto"><div><br></div><div>l8r</div><div>Sean<br><br>Sent from my iPad</div></div><div dir="auto"><div><br>On Sep 28, 2016, at 7:25 PM, Sean Heber <<a href="mailto:sean@fifthace.com" target="_blank">sean@fifthace.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>Pretty sure this is all way out of scope, but something about this made me think about this idea (which maybe isn't unique or is maybe even unworkable), but imagine something like where a new capture type is added such as "required" (for lack of another name right now). And the way this works is similar to unowned, but it makes the entire closure "weak" in such a way that the moment any of the required captures go nil, any references to that closure instance also effectively become nil.</div><div><br></div><div>So modifying the example:</div><div><br></div><div><div class="gmail_quote"><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">func viewDidLoad() {<br> self.loginForm.onSubmit = {[required self]<br> let f = self.loginForm<br> self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)<br> }<br>}</span></font></div></div><div><br></div><div>So in this case, "required self" means self is effectively "unowned" but any references to this closure would have to be weak optional like: weak var onSubmit: (()->Void)? So that when the view controller gets deallocated, the closure goes with it and references become nil.</div><div><br></div><div>l8r</div><div>Sean</div><br>Sent from my iPad</div><div><br>On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>It could potentially be a breaking change if the default for @escaping closures were made to be weak-capturing.<br></div><div><br></div><div>Since the weak-capturing pattern is only really desirable for @escaping closures, and (I think) it would be the usual preference, could @escaping also imply weak-capturing for all references (not just self)? Then there would be another syntax for strong-capturing-escaping closures. Non-escaping closures could a) strongly capture references; or b) existing strong references stay strong and weak ones stay weak, meaning no ref-counts need to change at all when passing them.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 29 Sep 2016 at 00:06 Paul Jack 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">So previously there were a few threads on the "strong self/weak self<br>
dance" but they didn't seem to get anywhere. For instance:<br>
<br>
<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html</a><br>
<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html</a><br>
<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html</a><br>
<br>
...and possibly others.<br>
<br>
I'd like to propose something even easier (and more specific) than all<br>
of the above discussions. Specifically, I'd like to introduce a new<br>
automagic closure variable, $self, whose presence in a closure would<br>
cause that closure to weakly capture self in a safe manner.<br>
<br>
As a concrete example, let's imagine a UIViewController for a login<br>
form. Under this proposal, the following code:<br>
<br>
func viewDidLoad() {<br>
self.loginForm.onSubmit = {<br>
let f = $self.loginForm<br>
$self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)<br>
}<br>
}<br>
<br>
...would be treated by the compiler as equivalent to:<br>
<br>
func viewDidLoad() {<br>
self.loginForm.onSubmit = {<br>
[weak self] in<br>
if let selfie = self {<br>
let f = selfie.loginForm<br>
selfie.startLoginRequest(email:f.email.text,<br>
pwd:f.pwd.text)<br>
}<br>
}<br>
}<br>
<br>
Note the "if let" there: If self no longer exists, the closure does not<br>
execute at all, but if self does exist, then it exists for the entirety<br>
of the execution of the closure (ie, self won't vanish as a side-effect<br>
of some statement in the closure.) I think these semantics obey the<br>
principle of least surprise; $self can be treated by the developer as a<br>
strong reference.<br>
<br>
However, that does mean that $self can only be used in a closure that's<br>
(a) Void or (b) Optional. In the latter case, returning nil when self<br>
doesn't exist seems like reasonable/expected behavior.<br>
<br>
It would be a compile-time error to use both $self and normal self in<br>
the same closure.<br>
<br>
I'd like to keep this simple, meaning $self always does the above and<br>
nothing else. So, if you need an unowned self, you still need the<br>
original syntax; if your closure needs a non-Optional return type, you<br>
still need the original syntax; etc.<br>
<br>
Thoughts?<br>
<br>
-Paul<br>
_______________________________________________<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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div></blockquote></div>
</div></blockquote></body></html>