Safe Memory Management and Ownership.

[jmh530]

On Friday, 13 July 2018 at 17:12:26 UTC, Atila Neves wrote:
>
> Rust can do that because it enforces it at compile-time. A D 
> solution wouldn't be able to do anything more with immutable 
> borrows.

Hmm, thinking on this a little more...it does seem 
difficult...but I don't think the problem is with immutable 
borrows. I think the issue is with the exclusivity of Rust's 
borrowing.

D's immutable is transitive so if you're using immutable at some 
point, then no one else can modify it anyway. So you should only 
be able to immutably borrow something that's immutable anyway.

Rust, by contrast, allows immutable borrows of mutable data. In 
some sense what Rust does corresponds more to const (or maybe 
head const), but it's more than just const. A Rust immutable 
borrow of mutable data prevents the mutable data from being 
modified during the borrow. The Rust example below involves an 
immutable borrow of mutable data, but it fails to compile because 
you modify x while it is borrowed. If you put y in a separate 
scope, then it compiles because x is no longer being borrowed 
after y exits the scope.

fn main() {
     let mut x = 5;
     let y = & x;
     x += 1;
}

This exclusivity also affects mutable borrows as well. Below does 
not compile because y controls x. Rust's mutable borrows are also 
exclusive. Only one is allowed at a time. So that same trickiness 
is applied here.

fn main() {
     let mut x = 5;
     let y = &mut x;
     x += 1;
}

The only thing that made sense to me about implementing this at 
compile-time was a template parameter that could disable things 
like opAssign.
https://run.dlang.io/is/FvJvFv
But being able to change the template parameter is tricky. You 
can cast it at run-time, but other that that it's beyond me.

On a separate note, I didn't have any success working with 
automem and const/immutable types.
https://run.dlang.io/is/el4h3e