[D-runtime] dup attributes?

[Steve Schveighoffer]

----- Original Message ----
> From: Fawzi Mohamed <fawzi at gmx.ch>
> To: D's runtime library developers list <d-runtime at puremagic.com>
> Sent: Fri, August 6, 2010 7:35:57 AM
> Subject: Re: [D-runtime] dup attributes?
> 
> On 6-ago-10, at 13:09, Steve Schveighoffer wrote:
> 
> > ----- Original  Message ----
> >> From: Fawzi Mohamed <fawzi at gmx.ch>
> >> 
> >> well it  is not so clear to me what the  flags of a~b should be if the flags  
>of
> >> a & b happens to be different.
> >> I  think that  probably always using the default type flags from the 
>typeinfo
> >>  for  the result is the way to go.
> > 
> > What about an  intelligent choice?  For example, the NO_SCAN bits should be
> >  and-ed.  That's what I was thinking.  But of course, this means N flag  
>lookups,
> > so there is a performance concern.
> 
> I dislike  "intelligent choices" if they have a cost and makes dependencies 
>less local (as  here),
> unless it is really what one would expect.
> In this case if I use a  global void[], of ubyte[] buffer to do concatenation 
>of arbitrary types of the  results change,
> and it is unclear how to extend the behaviour wrt. exact  scanning should be.
> It seems a source of hard to track bugs...
> 
> The  cost should not be really too much, but I prefer that the target type 
>"decides"  the correct flags.
> Using templates one can make it so that the target type is  the correct one.
> It is faster and, IMHO, logically as well founded as the  alternatives,
> thus I would keep the current behaviour (It is also less work  :).

Well, let me get to the root of the problem then :)

The issue is that phobos deals with void[] for things like I/O, which to me 
seems like the correct type.  It allows you to pass in any array type without 
casting, and it says "I don't know what type this is".  One of these functions 
is std.file.read() which reads the entire file into an array and returns that 
array as a void[].  Given that all the C functions use void *, it seems like the 
right call.  But problems come in because void[] has the NO_SCAN bit cleared, 
but this clearly has no pointers in it (the source is a file!).  So what to do?

std.file.read gets around this by calling gc_malloc directly.  However, it was 
rightfully pointed out that if one simply dups the array, or uses concatenation 
with it, it magically loses the NO_SCAN bit.  See the bug report here: 
http://d.puremagic.com/issues/show_bug.cgi?id=4572

OK, after writing all this, I'm going to change my mind :P  I just realized that 
the only time, and I'm pretty sure this is the *only* time, we have to worry 
about this is when you're concatenating two or more void[]'s.  This corner case 
seems highly unlikely. Append doesn't have the problem, and if you have casted 
your void[]'s to something else, then why not use that new type's bits?  I think 
you are right, concatenation should stay as is.

I guess concatenation is not an issue, and we agree that dup should replicate 
the flags.

OK, I'll go about making the change for dup.

-Steve