Plan for Exceptions and @nogc?

[via Digitalmars-d]

On Wednesday, 18 February 2015 at 20:25:07 UTC, Dicebot wrote:
> On Wednesday, 18 February 2015 at 18:26:34 UTC, deadalnix wrote:
>> On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote:
>>> From my POV best proposal from last lengthy discussion was to 
>>> enable reference-counted non-gc-heap Exceptions. But that 
>>> needs a language change because RefCounted!T is a struct and 
>>> thus neither can be thrown nor can be part of Throwable class 
>>> hierarchy.
>>>
>>
>> This is not satisfactory. First there is no safe way to 
>> refcount right now. Second, this has all kind of implication 
>> for the GC to scan the heap and so on. Finally this do not 
>> solve the type qualifier problem.
>>
>> I don't think a language change to do this pay for itself. i 
>> understand the appeal, as this is probably simpler to 
>> implement than the alternative, but that is really building 
>> technical debt.
>
> Right now I don't care for full memory safety or type safety of 
> any proposed solution. I will be glad to have any that actually 
> works - and I have not heard of any idea that allows to do that 
> without language changes. Your push for owned is also hardly 
> relevant because exceptions are good examples of data with 
> shared / non-determenistic ownership and thus won't benefit 
> from it.

Non-deterministic ownership is exactly what the owned concept 
helps with, because it allows to delay deciding on an actual 
management mechanism until it reaches the consumer. When someone 
catches an owned exception, they can then choose to store it in a 
non-owned variable (=> making it GC owned), in a ref-counted 
(which then takes ownership), or to not store it at all, in which 
case it will get released automatically when the catch block is 
left. Before that decision is made, it can still be used without 
losing the "owned" property, by passing it as a scope parameter 
(or storing it in a scope variable).