> On 20 Feb 2017, at 16:02, Matthew Johnson <matt...@anandabits.com> wrote: > > >> 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.
Will definitely give it a read :) Thanks! >> >>> -- >>> 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
