<div dir="ltr"><div><div>I think Sean's idea for [required refName] on this is the better one in terms of syntax and clarity of what's going on. It's fairly clear that the required refs are weak but become strong during the closure execution, and that since they're 'required' the closure goes away if they do.<br><br></div>In practice, with lazy zeroing I think it would not be viable to zero the closure ref until calling it was attempted and the strong ref on its required captures failed.<br></div>One for the 'deferred' pile I guess :P<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 29 Sep 2016 at 01:27 Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</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><blockquote type="cite"><div>On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><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></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Ok, but source breaking changes need extreme justification. A primary goal of Swift 3 was to provide source compatibility going forward.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>-Chris</div></div></div><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><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>
_______________________________________________<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></div></blockquote></div>