On 2014-05-31, at 20:44, Patrick Walton <pcwal...@mozilla.com> wrote:
> On 5/31/14 10:36 AM, Tommi wrote: >> Iterator invalidation (as it's known in C++) is a risk to memory >> safety only when some of the memory that is accessible through an >> iterator (or a reference) is deallocated. A better type system would >> make a distinction between those expressions that may deallocate and >> those that cannot. Then, when multiple mutating references pointed to >> the same variable, the compiler would disallow only the use of the >> potentially deallocating expressions through those references. > > Again, this is wrong. Iterator invalidation is the way I like to explain the > rule, but it is by no means the only thing that can go wrong if you have two > &mut references to the same location. If you have two &mut pointers to the > same memory address, it is quite easy to write cast::transmute in safe code > without any iterators or memory being deallocated at all. I don't understand that last sentence. How could you use `transmute` in safe code given that it's an `unsafe` function? By the way, I said previously that: >> Then, when multiple mutating references pointed to >> the same variable, the compiler would disallow only the use of the >> potentially deallocating expressions through those references. ...but I'd like to rephrase that: The compiler should make sure that you can't deallocate memory that could potentially be accessible through multiple different variables (be they references or owning variables). But all other kind of mutation through different variables in a single-threaded code should be memory-safe at least in some definition of that word.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
