> On Feb 6, 2017, at 3:41 PM, Erik Eckstein <eeckst...@apple.com> wrote:
>
> 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?
The no return function in a certain sense causes the scope for x to never end.
So no cleanup is needed. The cleanup for x should be after bar always.
>
> Erik
>
>> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev
>> <swift-dev@swift.org <mailto: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
>>
>>>
>>> Jordan
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
