What have I missed?

[H. S. Teoh via Digitalmars-d]

On Fri, Aug 08, 2014 at 11:30:07PM +0000, Era Scarecrow via Digitalmars-d wrote:
[...]
>  I recall trying to satisfy everyone's requests. The only thing that
> really came up was it was sometimes a reference (>64 bits) and
> sometimes a value type (<=64 bits) and that was confusing only because
> it wasn't consistent.  That and someone wants to be able to have a
> static size that probably doesn't rely on allocation at all. Possible
> but not sure how to make it...
> 
>  As someone mentioned before, i think it comes down that we really
> aren't sure what it is really for, it hasn't been fully defined. Is it
> a storage container? An array? Is it mostly so we can foreach over the
> elements for something? Is it for bit packing/unpacking for
> compression? (Which is how i see it mostly). Encryption?
[...]

I think this indicates that perhaps there is not a single BitArray type
that will satisfy everybody, but perhaps 2-3 related types that share
some algorithms.  At least the following types come to mind (these are
all temporary names so please don't bust out the rainbow bikeshed just
yet):

- SmallBitArray: fits inside a ulong, and has value semantics. Behaves
  like a ulong: minimal cost for passing it around, making multiple
  copies of it, etc.. Basically for juggling bits in a ulong.

- StaticBitArray: a value type that fits inside n ulong's. Appends only
  work up to the max capacity of n ulong's. This one is mainly for
  people who need to manipulate bitmasks, perform bit operations en
  masse, etc.. Backed by an embedded static array, so it has value
  semantics, and you can pass it around, copy it, etc., without worrying
  about aliasing.

- DynamicBitArray: a reference type backed by the GC. This one is for
  people who are after something that behaves like D dynamic arrays;
  slicing is supported (by means of extra info about how many bits at
  the beginning/end of the array is actually part of an array, so you
  can slice it at arbitrary bit positions not aligned with word
  boundaries), as is arbitrary appending, etc.. The emphasis for this
  one is memory efficiency (e.g. for people who need to store massive
  numbers of bools without wasting an entire byte per bool), at the cost
  of potentially slower copying / overhead of maintaining start/end bit
  indices, etc..

Obviously, these types are closely related, so they will probably share
quite a good number of common algorithms. So potentially they can be
implemented as a core of common functions that can work on all 3
BitArray types, with a few customized methods for each type.


T

-- 
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of
thought about your programming problem.  In the end they wind up
contributing one or two pieces to the collective wisdom, and fade away
in the rearview mirror. -- Walter Bright