In C#, it's possible that class members can actually be destroyed before the containing object.

Example:

class Stuff
{
    Class1 thing1;
    Class2 thing2;

    ~Stuff() {
        thing1.DoSomeFinalization();  //  [1]
    }
}

I forget what the exact behavior was, but basically, [1] is unsafe because it may have already been destructed/freed by the time ~Stuff() is called.

Is this also true for D?

  Bit

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.

On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe <destructionator@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.

I have heard about attempts to add precise GC to D though... would precise GC address this problem in some way?

  Bit

On 5/19/15 2:37 PM, bitwise wrote:
> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
> <destructionator@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's actually quite impossible for the GC to know what pointers are "owning" pointers and what ones are not. And you could never have ownership cycles.

You could use some version of malloc/free to do it. But you have to take care of GC references inside that malloc'd block.

> I have heard about attempts to add precise GC to D though... would
> precise GC address this problem in some way?

No. Precise scanning just (potentially) cuts down on scanning time, and avoids false pointers.

-Steve

On Tue, 19 May 2015 14:55:55 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On 5/19/15 2:37 PM, bitwise wrote:
>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>> <destructionator@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's actually quite impossible for the GC to know what pointers are "owning" pointers and what ones are not. And you could never have ownership cycles.
>
> You could use some version of malloc/free to do it. But you have to take care of GC references inside that malloc'd block.
>
>> I have heard about attempts to add precise GC to D though... would
>> precise GC address this problem in some way?
>
> No. Precise scanning just (potentially) cuts down on scanning time, and avoids false pointers.
>
> -Steve

Ok, thanks for the quick answers =D

  Bit

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@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.

On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x 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@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.

By the way: when is 2.068 released?

On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
> On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x 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@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.
>
> By the way: when is 2.068 released?

"After dconf"
http://forum.dlang.org/thread/5554D763.1080308@dawg.eu#post-5554D763.1080308:40dawg.eu

On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
> On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
>> On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x 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@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.
>>
>> By the way: when is 2.068 released?
>
> "After dconf"
> http://forum.dlang.org/thread/5554D763.1080308@dawg.eu#post-5554D763.1080308:40dawg.eu

I thought the new releases would come faster.

On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous@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@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