<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 11:44 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 11:25, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Feb 6, 2017, at 11:22 AM, Michael Gottesman <<a href="mailto:mgottesman@apple.com" class="">mgottesman@apple.com</a>> wrote:<br class=""><br class="">Here is my suggestion:<br class=""><br class="">1. We assume by default the leaking case.<br class="">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).<br class=""></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">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.</div></div></blockquote><br class=""></div><div class="">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 <i class="">sooner;</i> usually more awkward to get them to stay alive.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Michael</div></div></div></div></blockquote></div><br class=""><div class=""><div class="">Sorry I didn't jump in yesterday. I'm afraid I don't follow most of the reasoning expressed in the thread. I do completely understand Jordan's points.</div><div class=""><br class=""></div><div class="">'noreturn' functions are called from may-return functions. Guaranteeing cleanup would result in inconsistent behavior as a result of optimization.</div><div class=""><br class=""></div><div class="">The optimizer can always shorten lifetimes when it determines that the caller can't access the object. But I don't see what that has to do with 'noreturn'.</div><div class=""><br class=""></div><div class="">I agree that we *could* add a special "cleanup before" semantic tag for some C functions, but I'm not aware of a need to do that and there are definite drawbacks.</div></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>