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 [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
