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
