> On Feb 6, 2017, at 2:25 PM, Joe Groff via swift-dev <swift-dev@swift.org> > wrote: >> On Feb 6, 2017, at 11:22 AM, Michael Gottesman <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 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 think I agree with this. :) One reasonable approach to fixing the user problem Michael is identifying without providing special-case behavior to noreturn calls would be to simply make a stronger language guarantee about value liveness in general. For example, we could say that if a value is "obviously" not used in or after a particular statement, then it is guaranteed to have been destroyed before that statement executes. We can use the same definition of "obvious" that DI uses, which gives us a clear implementation path: we just run a lifetime-shortening pass as a mandatory optimization, possibly even as part of DI. Of course, that's not necessarily great for debugging. John. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
