Scope Containers

[Atila Neves]

On Wednesday, 13 March 2019 at 11:35:02 UTC, Olivier FAURE wrote:
> On Wednesday, 13 March 2019 at 08:49:37 UTC, Atila Neves wrote:
>> [...]
>
> One possibility might be to implement at run time what rust 
> does at compile time, eg make it impossible to mutate vector as 
> long as one or more readable view to its content exists.
>
> So for instance, make opSlice and opIndex return a struct that 
> bumps a reference counter up inside the vector; the counter is 
> bumped down once that struct is destructed. As long as the 
> number of "live" slices is non-zero, the vector isn't allowed 
> to re-allocate.
>
>> [...]
>
>> [...]
>
> I don't think that's the point.
>
> It's supposed to be *impossible* to get a memory corruption in 
> @safe code. Not "convoluted and wouldn't pass code review", 
> impossible. When you write a @trusted function, getting a 
> memory corruption with that function is supposed to be 
> impossible as well.
>
> Other people have gone over why memory safety is necessary 
> before. Not all code goes through code review, sometimes review 
> miss errors even for critical applications, etc.

I just tagged v0.6.0.

I made `opSlice` `@system` given what has been discussed here.

I introduced a new member function `range` which return a forward 
range that keeps a pointer to the vector inside of it. Coupled 
with dip1000 it seems to do the trick.

I also made it so `Vector` is no longer an input range itself.