> On Feb 6, 2017, at 11:25, 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'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.

Jordan
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to