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.
l8r
Sean
Sent from my iPad
> On Sep 28, 2016, at 7:25 PM, Sean Heber <s...@fifthace.com> wrote:
>
> 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.
>
> So modifying the example:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {[required self]
> let f = self.loginForm
> self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
>
> 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.
>
> l8r
> Sean
>
> Sent from my iPad
>
>> On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> It could potentially be a breaking change if the default for @escaping
>> closures were made to be weak-capturing.
>>
>> 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@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
