Workaround for typeid access violation

[rsw0x via Digitalmars-d]

On Tuesday, 16 June 2015 at 16:28:54 UTC, Etienne wrote:
> On Tuesday, 16 June 2015 at 15:39:06 UTC, rsw0x wrote:
>> destructors as they are shouldn't exist at all, they are 
>> incredibly bug prone.
>>
>> Bye.
>
> To be fair, everything is bug prone until you understand them.

No, they are just bug prone.

> GC finalization is done in a single lock, none of the memory is 
> re-used, so objects can have their own "destroyed" flags and 
> destroy eachother fine if the typeinfo issue isn't there.

Implementation-defined behavior.

>
> On the other hand, by keeping the GC destructors, we must agree 
> that all the destructors are declared this way:
>
> shared @nogc nothrow ~this()
>
> Only then can we count it in as having predictable behavior.

Still not predictable, as they can be ran in any thread, in any 
order, and be ran parallel.

>
> I can't really agree on removing finalizers, I'd really love to 
> master GC destructors in D so that I can return plain class 
> objects from my functions with data allocated elsewhere, like 
> in any managed language out there. It's really the only way. 
> Don't get me wrong, I allocate and free on a freelist or pool 
> everywhere I can, but the GC has its advantages and I'd really 
> like to put it to work (safely) to build more convenient APIs.

You're attempting to use GC for a problem that they don't solve 
because you don't have other tools to fix it. When all you have 
is a hammer, everything looks like a nail.