DIP 1008 Preliminary Review Round 1

Atila Neves via Digitalmars-d digitalmars-d at puremagic.com
Fri May 26 11:58:21 PDT 2017


On Friday, 26 May 2017 at 11:50:40 UTC, Steven Schveighoffer 
wrote:
> On 5/26/17 4:49 AM, Walter Bright wrote:
>> On 5/25/2017 4:54 PM, Atila Neves wrote:
>>> I think maybe the problem isn't with `throw` but with 
>>> `catch`. What if
>>> instead we make it so that:
>>>
>>> catch(scope T ex) { /*...*/; }
>>>
>>> Means:
>>>
>>> catch(scope T ex) { /*...*/; ex.__dtor; }
>>
>> The trouble comes in when one starts copying exception 
>> references
>> around. Who then is responsible for destroying it?
>
> This isn't the trouble. The trouble is that `new Exception` is 
> not @nogc, and there isn't a way to fix all existing exception 
> code easily.

True, but a hypothetical `NoGcException.create` _is_ `@nogc` 
(same as my MallocException), and is there really any difference 
between reading/writing `new Foo` and `Foo.create`?

Also, there's `enforce`, which is where I suspect a lot of 
throwing happens anyway. It could use DbI to figure out from the 
exception type what to do.

> My $0.02: Either we are going to make `new Exception` be @nogc, 
> or we are going to require people to type something different.

Or be able to customise `new T`, which feels less hacky than it 
magically meaning something different if the type is a Throwable. 
I know that there were class allocators in D1 and that they're 
depecreated but I wasn't around back then to know why.

Atila



More information about the Digitalmars-d mailing list