[phobos] custom BlkAttr flags

[Steve Schveighoffer]

I added the fix for the comma, sorry for that.  All the other places had an 
ALL_BITS enum member, so the NO_MOVE line that I copied and changed had a 
comma.  I thought I compiled before I checked in, but I guess I did not.

Regarding the bit being flipped, yes I want the default meaning to be "no 
append" because anyone can allocate memory via GC.malloc for any purpose, and 
GC.malloc does not initialize the "allocated length" field inside the block, so 
it is not appendable.  It does not mean you cannot append to the block, it just 
means the first append will reallocate into an appendable block.

Regarding using the typeinfo, that doesn't work.  Arrays can easily be created 
out of blocks that weren't allocated via the array creation routines.  Think of 
void[], and GC.malloc above.

-Steve




----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Wed, July 14, 2010 12:25:09 AM
> Subject: Re: [phobos] custom BlkAttr flags
> 
> On Jul 13, 2010, at 8:09 AM, Steve Schveighoffer wrote:
> > 
> > What I  propose to fix this is to allocate one of the block attribute flags 
>to 
>
> >  designate that a block is appendable.  The odd part about it, is that the  
>GC is 
>
> > not aware of appending, so it is somewhat of a "user-defined"  flag.
> > 
> > My question is, how should we declare the flag?  I  currently only defined it 
>in 
>
> > lifetime.d, outside the gc, but I'm  thinking it should be defined in the GC 
>as 
>
> > well.  Also, should I  allocate the next bit, or one of the higher order 
>bits?
> > 
> > I'm  going to check in my code that defines it in lifetime.d only, and 
>depending 
>
> > on the responses to this, I'll add it to the GC definition  too.
> 
> Your checkin doesn't compile.  I added the requisite comma for  now to fix 
>this.  That aside, assuming this design were to be kept I think  the meaning of 
>the bit has to be flipped.  The bit defaults to unset, so  that should be the 
>default meaning.  You really don't want all blocks to be  appendable by default, 
>do you?  More generally, if we start holding  TypeInfo references in the GC then 
>we should be able to determine appendabiility  based on whether the TypeInfo is 
>an array type.  This may not make the next  release, but I'd like to address it 
>once I've polished std.concurrency a bit  more.
> _______________________________________________
> phobos mailing  list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>