[swift-evolution] $self

[Jay Abbott]

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.

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.
One for the 'deferred' pile I guess :P

On Thu, 29 Sep 2016 at 01:27 Chris Lattner <clattner at apple.com> wrote:

> On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> It could potentially be a breaking change if the default for @escaping
> closures were made to be weak-capturing.
>
>
> Ok, but source breaking changes need extreme justification.  A primary
> goal of Swift 3 was to provide source compatibility going forward.
>
> -Chris
>
>
>
> 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.
>
>
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>
>> ...and possibly others.
>>
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>>
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>>
>> func viewDidLoad() {
>>     self.loginForm.onSubmit = {
>>          let f = $self.loginForm
>>          $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>>     }
>> }
>>
>> ...would be treated by the compiler as equivalent to:
>>
>> func viewDidLoad() {
>>     self.loginForm.onSubmit = {
>>          [weak self] in
>>          if let selfie = self {
>>              let f = selfie.loginForm
>>              selfie.startLoginRequest(email:f.email.text,
>>              pwd:f.pwd.text)
>>          }
>>     }
>> }
>>
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the closure (ie, self won't vanish as a side-effect
>> of some statement in the closure.) I think these semantics obey the
>> principle of least surprise; $self can be treated by the developer as a
>> strong reference.
>>
>> However, that does mean that $self can only be used in a closure that's
>> (a) Void or (b) Optional. In the latter case, returning nil when self
>> doesn't exist seems like reasonable/expected behavior.
>>
>> It would be a compile-time error to use both $self and normal self in
>> the same closure.
>>
>> I'd like to keep this simple, meaning $self always does the above and
>> nothing else. So, if you need an unowned self, you still need the
>> original syntax; if your closure needs a non-Optional return type, you
>> still need the original syntax; etc.
>>
>> Thoughts?
>>
>> -Paul
>> _______________________________________________
>> 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/20160929/d71228eb/attachment.html>