Scope Containers

[Olivier FAURE]

On Wednesday, 13 March 2019 at 08:49:37 UTC, Atila Neves wrote:
> Either way, thanks for pointing out the possible issue. I'm 
> going to have to think long and hard about whether it's 
> possible to fix it with the language we have now.

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.

> The code in the github issue is problematic, but it's a far cry 
> from how such errors are usually introduced in C++. Normally 
> it's because another thread has a reference to the now dangling 
> pointer, or calling a function with the slice means it gets 
> escaped somewhere.

> Which is also convoluted. Neither case would pass code review.

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.