BitArray new design - slice problems

[Era Scarecrow]

On Friday, 18 January 2013 at 16:42:04 UTC, Dmitry Olshansky 
wrote:
> Slices should have a pointer and length so they can check range 
> (in debug builds), alternatively just a pointer to storage that 
> nows the range.

  So write an alternate opIndex...

> I think slice ops could be made @safe if the primitives for 
> bulk transfer and opIndex in the Storage are @trusted.
>
> If we just mark all of opSlice on Fixed-sized one as @system 
> then it should be good enough. In other words (I'm lost in 
> terminology):
>

<snip>

> The idea is to make code responsible for the "root" of unsafety 
> to be @system everything else then can be @safe or 
> @trusted(where compiler can't see it).

  Hmmm okay... Somehow this seemed so much more complex than it's 
put here.

> I think that the most of slice ops can be @safe/@trusted. It's 
> the process of taking a slice out of stack-based container that 
> is not @safe. The one taking a slice out of GC-based one is 
> @safe.

  And depending on if it is fixed or dynamic will determine if the 
slice is @system or @safe... Makes sense. That sets me straight.


  So for the slice/range, what all should it support? I've tried 
to have it support (or foward) opBinary, opBinaryAssign, 
comparing, slicing, copying, as well as inputRange, 
bidirectional, opIndex & opIndex assign, opDollar and length. If 
it should support a much smaller sub-set I'll need to know; Could 
greatly affect how it is written.