Well got a few curious problems. Slicing doesn't seem it wants
to work as a separate type and can cause problems.
Let's take an example. Say our slice is..
struct BitArraySlice {
BitArray* ba;
ulong start, end;
}
Now how much does it depend on the bitarray that it's pointing
to? If it is a wrapper then we have a problem with range checks
which should be legal.
BitArray x = BitArray(100); //100 elements
auto sl = x[50 .. 100];
x.length = 50;
sl[0] = true; //out of range! BitArray valid from 0-49, not
50-100
That much is sorta easy to fix with a separate opIndex (and
fixed sizes), but it's possible to re-slice the dynamic array to
make it smaller. So even if we have opIndex allow out of ranges...
struct BitArray {
size_t[] store; //storage
ubyte start, end;
}
BitArray x = BitArray(100); //100 elements
auto sl = x[50 .. 100];
//likely does x.store[] = x.store[0 .. 2];
//due to compact 1 byte offsets to determine end of bitarray.
x.length = 50;
sl[0] = true; //ok, 0-64 valid on 32bit machines
sl[32] = true; //out of range! 82 past not within 0-63
So let's take the slice and give it the address of the storage
instead, other than it could point to a local variable it will
work; But now I have basically two definitions of bitarray, one
that can be a range/slice while the other that manages the memory
and binary operators.
struct BitArraySlice {
//same as BitArray now, what advantage does this give?
size_t[] store;
ulong start, end;
}
Seems like making the slices a separate entity is going to cause
more problems (Not that they can't be solved but the advantages
seem smaller); Plus there's issues trying to get immutable/idup
working.
Thoughts? Feedback? I'm about ready to drop this and resume my
previous version and enhance it with recent experiences.
