<div dir="ltr"><div><div>I think Sean&#39;s idea for [required refName] on this is the better one in terms of syntax and clarity of what&#39;s going on. It&#39;s fairly clear that the required refs are weak but become strong during the closure execution, and that since they&#39;re &#39;required&#39; 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 &#39;deferred&#39; pile I guess :P<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 29 Sep 2016 at 01:27 Chris Lattner &lt;<a href="mailto:clattner@apple.com">clattner@apple.com</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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 &quot;strong self/weak self<br>
dance&quot; but they didn&#39;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&#39;d like to propose something even easier (and more specific) than all<br>
of the above discussions. Specifically, I&#39;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&#39;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 &quot;if let&quot; 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&#39;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&#39;s<br>
(a) Void or (b) Optional. In the latter case, returning nil when self<br>
doesn&#39;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&#39;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>