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
