I’m not sure if I understood.
What if there is a call to a function and that conditionally calls a noreturn
function:
func foo() {
let x = Myclass()
bar(true)
// release x here?
}
func bar(_ dontReturn: Bool) {
if (dontReturn) {
noreturn_func()
}
}
Is it even possible to “clean up before” in such a case?
Erik
> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev
> <[email protected]> wrote:
>
>>
>> On Feb 6, 2017, at 11:44 AM, Jordan Rose <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Feb 6, 2017, at 11:22 AM, Michael Gottesman <[email protected]
>>>> <mailto:[email protected]>> 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
>
> _______________________________________________
> swift-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-dev
> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
