what to do with postblit on the heap?

[Steven Schveighoffer]

On Mon, 20 Jun 2011 11:03:27 -0400, bearophile <bearophileHUGS at lycos.com>  
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