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

Reply via email to