GC: memory collected but destructors not called

[Steven Schveighoffer via Digitalmars-d]

On 11/12/14 12:05 AM, Shachar Shemesh wrote:
> On 11/11/14 22:41, Steven Schveighoffer wrote:
>>
>> At this point, I am not super-concerned about this. I cannot think of
>> any bullet-proof way to ensure that struct dtors for structs that were
>> meant only for stack variables can be called correctly from the GC.
> Isn't "structs meant only for stack variables" a semantic thing? The D
> compiler cannot possibly know. Shouldn't that be the programmer's choice?
>
>> This
>> pull doesn't change that, and it does have some nice new features that
>> we do need for other reasons.
>>
>> In other words, putting a struct in the GC heap that was written to be
>> scope-destroyed is an error before and after this pull. Before the pull,
>> the dtor doesn't run, which is wrong, and after the pull the dtor may
>> cause race issues, which is wrong. So either way, it's wrong :)
> I disagree.
>
> The first is wrong. The second is a corner case the programmer needs to
> be aware of, and account for.

The programmer being the user of the struct or the designer? It's 
impossible to force the user to avoid using a struct on the GC, it would 
be enforcement by comment.

But even then, in your dtor, there are issues with accessing what a dtor 
would normally access. Tell me how you implement reference counting 
smart pointer when you can't access the reference count in the dtor...

> The difference is that, in the first case,
> the programmer is left with no tools to fix the problem, while in the
> second case this is simply a bug in the program (which, like I said in
> another email, also happens with the current implementation when the
> struct is inside a class).

Sure there are tools, you can wrap the struct in a class if you like 
pain and suffering. Having the struct dtor called without the wrapper is 
the same issue.

> In other words, the second case exposes a second (more direct and more
> likely to be handled) path to an already existing problem, while the
> first puts the programmer up against a new problem with no work around.

This means all struct dtors need to be thread aware, and this is not 
what you want in a language where the type information dictates whether 
it can be shared or not.

-Steve