> 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

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.

'noreturn' functions are called from may-return functions. Guaranteeing cleanup 
would result in inconsistent behavior as a result of optimization.

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'.

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.

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

Reply via email to