BitArray new design - slice problems

[Dmitry Olshansky]

18-Jan-2013 01:49, Era Scarecrow пишет:
> On Thursday, 17 January 2013 at 19:36:34 UTC, Dmitry Olshansky wrote:
>> I'm thinking that a opSlice of stack-allocated must be @system and a
>> heap allocated can be @safe.
>
>   That's just a small part of the problem. With the new design, 90% of
> it can be safe; Just the actual slice buffer when you request it (with
> Fixed storage) would be @system,and slices (having a pointer)

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.

  But
> @safe code can't call @system code which means that the current design
> (convert to slices before operations) it all has to all be @system.
>

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):

FixedBitArray!(1024) fixed;
auto slice = fixed[0..100]; //this is @system
slice[10..20] = slice[20..30]; //this is @safe
foreach(bool x; slice[0..10])  //this is @safe
{... }

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).

>   Guess once it's debugged the entire thing can be @trusted and only
> certain things can be marked @system instead.

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.

-- 
Dmitry Olshansky