GC Destruction Order

[bitwise via Digitalmars-d-learn]

On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous at anonymous.com> wrote:

> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe  
>> <destructionator at gmail.com> wrote:
>>
>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>> Is this also true for D?
>>>
>>> Yes. The GC considers all the unreferenced memory dead at the same  
>>> time and may clean up the class and its members in any order.
>>
>> Ugh... I was really hoping D had something better up it's sleeve.
>
> It actually does, check out RefCounted!T and Unique!T in std.typecons.  
> They're sort of limited right now but undergoing a major revamp in 2.068.

Any idea what the plans are?. Does RefCounted become thread safe?

Correct me if I'm wrong though, but even if RefCounted itself was  
thread-safe, RefCounted objects could still be placed in classes, at which  
point you might as well use a GC'ed class instead, because you'd be back  
to square-one with your destructor racing around on some random thread.

I'm finding it hard to be optimistic about the memory model of D.

The idea of marking absolutely everything in your program with "@nogc"  
just to make it safe is ludicrous.

Something like this would be a little more reasonable, but I see no  
discussions about it:
@nogc module my_module;
or
@nogc class Something{}

DIP74 seems like it would improve the situation a lot, but wouldn't work  
as expected as long as any other class that may contain it could be GC'ed.  
This also seems like a monumental undertaking that won't actually be  
implemented for years, if at all.

I'm hoping someone will correct me here, because other than the memory  
model, D seems like a very well designed language.

   Bit