BitArray new design - slice problems

[Era Scarecrow]

On Thursday, 17 January 2013 at 18:12:28 UTC, Dmitry Olshansky 
wrote:
> Well, the slice was invalidated by shrinking an array. I don't 
> expect the below to work.

  It just seems like shrinking/expanding the array should still 
work, perhaps I'm thinking of them too much like a normal array 
slice. If this is acceptable behavior then okay, but the 
increased complexity may not be worth it.

> The good part is that error can be detected easily. In c++ for 
> instance it typically isn't.


> The harder problem is what to do when the original BitArray 
> goes out of scope. I guess in case of storage allocated on heap 
> it should work but if on the stack it shouldn't (and can't).

  Passing back the BitArray in either form is valid, as dynamic 
stays valid and a full binary copy stays valid. The slices on the 
other hand won't be valid unless it's on the heap.


>>   sl[0] = true; //ok, 0-64 valid on 32bit machines
>>   sl[32] = true; //out of range! 82 not within 0-63
>
> That's why it's far better to allow slices to be invalidated 
> depending on the length parameter of BitArray pointed by. 
> Compact array do weird things in the previous version too.

  Hmmm...

>> 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.
>>
>> 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.
>>
>
> Slices are ranges and thus are converted to array via 
> std.array.array, nothing to invent or re-implement.
>
>>  Thoughts? Feedback? I'm about ready to drop this and resume 
>> my previous version and enhance it with recent experiences.
>
> Feel free to do it how you see it. It's just that I think the 
> semantics of the previous version can't be improved to a 
> consistent state.

  Sure they can, drop the compact part of it and leave it fully 
dynamic (or vise-verse). But that would make some people unhappy; 
On the other hand we could go hybrid where I take the new storage 
implementations and allow template versions based on needs, 
remove the compact related stuff, but then it's almost back to 
the separate slice design. Hmmm...

  Should the slices be 'use at your own risk' when you tamper with 
the original BitArray? How else should it be?