On Mon, 20 Jun 2011 11:03:27 -0400, bearophile <[email protected]>
wrote:
Steven Schveighoffer:
The other part of this puzzle that is missing is array assignment, for
example a[] = b[] does not call postblits. I cannot fix this because
_d_arraycopy does not give me the typeinfo.
This seems fixable. Is it possible to rewrite _d_arraycopy?
The compiler is the one passing the parameters to _d_arraycopy, so even if
I change _d_arraycopy to accept a TypeInfo, the compiler needs to be fixed
to send the TypeInfo.
I think this is really a no-brainer, because currently what is passed is
the element size, which is contained within the TypeInfo. I will be
filing a bug on that. But currently, I can't fix it.
Anyone else have any thoughts?
I think the current situation is not acceptable. This is a problem quite
worse than _d_arraycopy because here some information is missing. Isn't
this is the same problem with struct destructors?
This is an easy fix -- the typeinfo contains information of whether or not
and how to run the postblit. The larger problem is the GC not calling the
destructor.
But my immediate question is -- is it better to half-fix the problem by
committing my changes, or leave the issue alone?
A solution is to add this information at runtime, a type tag to structs
that have a postblit and/or destructor. But then structs aren't PODs any
more. There are other places to store this information, like in some
kind of associative array.
Any solution that fixes the GC problem will have to store the typeinfo
somehow associated with the block. I think we may have more traction for
this problem with a precise GC.
I don't think the right route is to store type info inside the struct
itself. This added overhead is not necessary for when the struct is
stored on the stack.
Another solution is to forbid what the compiler can't guarantee. If a
struct is going to be used only where its type is known, then it's
allowed to have postblit and destructor. Is it possible to enforce this?
I think it is. Here an @annotation is useful to better manage this
contract between programmer and compiler.
This is a possibility, making a struct only usable if it's inside another
such struct or inside a class, or on the stack.
-Steve
