> On Feb 20, 2017, at 12:20 AM, David Hart <da...@hartbit.com> wrote: > > > On 20 Feb 2017, at 06:05, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >>> On Feb 19, 2017, at 7:06 PM, Matthew Johnson <matt...@anandabits.com> wrote: >>> >>> Often you hand it to something owned by self, but it's also the case that >>> you often hand it to something not owned by self, but that should not >>> extend the lifetime of self. >> >> I don't agree that it shouldn't extend the lifetime of `self`. By default, >> Swift assumes that if you capture an object in a closure, you want that >> object to stay alive as long as the closure does.
I was not being clear. What I meant is that when you register a method as a callback with something like NSNotificationCenter you usually do not want self to be retained by that callback registration. I agree that this proposal didn’t adequately address making the semantics visible at the call site and it was also too focused explicitly on self. But the basic statement is still true: today we use weak capture manually. We don’t *intend* for the lifetime of self to be extended and registering a callback that *does* extend the lifetime of self (or any other object) is often an error. >> >> I see absolutely no reason that this assumption should be different for >> `self` than it is for any other variable, and I see no reason to believe the >> caller would have a particularly good idea about this. > > Totally agree. The proposal would complicate reasoning about reference cycles > and lifetime of objects by creating special cases which depend on what > variable is concerned (self or other) and what the API does. I agree that this proposal had flaws. It was a step in the thought process which led to the new guarded closures proposal which is much stronger. > >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> 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
