DIP 1008 Preliminary Review Round 1
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 26 12:31:26 PDT 2017
On 5/26/17 2:58 PM, Atila Neves wrote:
> 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`?
There isn't, but Foo.create doesn't exist in current code. Someone has
to go through it all and update.
Note that the implication in your strawman is that you need a special
exception to be nogc. I'd rather leave the (de)allocation of the
exception up to the thrower/catcher, and have the exception not care
about its own location.
> 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.
Good point, we could change enforce, and that would fix a lot of the
usage of exceptions.
>
>> 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.
Deprecated, but still there.
However, it's the auto-destruction that isn't there. There isn't a way
to tell the compiler to destroy on the catch scope automatically.
Currently, when you override class allocation, you need to explicitly
delete.
-Steve
More information about the Digitalmars-d
mailing list