[swift-dev] No return functions and program exit

Michael Gottesman mgottesman at apple.com
Mon Feb 6 14:19:27 CST 2017


> On Feb 6, 2017, at 11:44 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> 
>>> On Feb 6, 2017, at 11:22 AM, Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170206/d5502395/attachment.html>


More information about the swift-dev mailing list