BitArray/BitFields - Resumed and polishing

[Era Scarecrow]

  As BitArray is coming back up and my resumed work I'll comment a 
few questions and suggestions and go from there. I'll polish up 
the code and try to resubmit it.

On Saturday, 28 July 2012 at 21:07:31 UTC, Jonathan M Davis wrote:
> I would point out that while hasSlicing doesn't currently check 
> for it, if opSlice doesn't return a type which is assignable to 
> the original range, it won't work in a lot of Phobos functions. 
> I keep meaning to bring that up for discussion in the main 
> newsgroup. I'd argue that hasSlicing really be changed from

  Hmmm.. Well Since the 'sometimes ref' as discussed won't seem to 
work well from before I'm considering to put the following two 
rules into effect.
1) If it's an allocated block, it stays allocated.
2) If you dup a BitArray and it's small enough to be compact, it 
converts.
3) If it's a small/compact array and you give out a slice, it 
converts the original block to dynamic before returning the new 
slice.

  With 1 & 2, reserved and length work a little differently, more 
ref friendly.
  With 3 the only issue comes up with if it's const, or a local 
variable.

  const BitArray x = BitArray(32);
  func(x);

  Would the function get passed the original compact buffer? Copy 
of x or a dup?
  May not be so much an issue. However...

  BitArray x = BitArray(32);
  const y = x[]; //slice

  Now if y points to the actual compact buffer and we do the 
following...

  x.length = 256; //allocates if it was compact

  Although y will have const access the data instead of a compact 
array it's a pointer to an array and broken. If during the x call 
it reallocated then y would work fine no matter what in that 
case. If x can't reallocate it, then the issue remains but is 
much smaller than before, most likely a dup would be safest.

  Thoughts? Questions? Ideas?