I’m not sure if I understood. What if there is a call to a function and that conditionally calls a noreturn function:
func foo() { let x = Myclass() bar(true) // release x here? } func bar(_ dontReturn: Bool) { if (dontReturn) { noreturn_func() } } Is it even possible to “clean up before” in such a case? Erik > On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev > <swift-dev@swift.org> wrote: > >> >> On Feb 6, 2017, at 11:44 AM, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >> >>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> >>>> On Feb 6, 2017, at 11:22 AM, Michael Gottesman <mgottes...@apple.com >>>> <mailto:mgottes...@apple.com>> wrote: >>>> >>>> Here is my suggestion: >>>> >>>> 1. We assume by default the leaking case. >>>> 2. We change noreturn functions from C to maybe have a special semantic >>>> tag on them that says that cleanups should occur before them (i.e. >>>> UIApplicationMain). >> >> I'm not sure what you mean by this. Functions from C exist in both groups, >> and I don't see why one assumption is better than the other. >> >> >>> >>> I feel that "clean up before" is the safer ground case, and if we do any >>> work to whitelist a group, it should be for the common "leakable" >>> noreturns, like exit/_exit/abort/fatalError. That way, we momentarily burn >>> some pointless cycles in the case we get it "wrong" rather than permanently >>> leak memory. >> >> I don't like this because of the reverse issue: under -Onone, you may want >> to pop back up the stack in the debugger and see what values you had, and >> they won't be available. It's almost always possible to get things released >> sooner; usually more awkward to get them to stay alive. > > On the other hand, this is safe to do in the short term. We can special case > asserts. One thing to consider though is if this should be provided to users. > If not, we can just use semantics. Otherwise, we would need to discuss how to > surface this at the language level. > > Michael > >> >> Jordan > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org <mailto:swift-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-dev > <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev