Why does Rust disallow mutable aliasing?

by

A really common pitfall in C++ programs, and even in Java programs, is modifying a collection while iterating over it, like this:

for (it: collection) {
    if (predicate(*it)) {
        collection.remove(it);
    }
}

For C++ standard library collections, this causes undefined behaviour. Maybe the iteration will work until you get to the last entry, but the last entry will dereference a dangling pointer or read off the end of an array. Maybe the whole array underlying the collection will be relocated, and it’ll fail immediately. Maybe it works most of the time but fails if a reallocation happens at the wrong time. In most Java standard collections, it’s also undefined behaviour according to the language specification, but the collections tend to throw ConcurrentModificationException – a check which causes a runtime cost even when your code is correct. Neither language can detect the error during compilation.

This is a common example of a data race caused by concurrency, even in a single-threaded environment. Concurrency doesn’t just mean parallelism: it can also mean nested computation. In Rust, this kind of mistake is detected during compilation because the iterator has an immutable borrow of the collection, so you can’t mutate the collection while the iterator is alive.

An easier-to-understand but less common example is pointer aliasing when you pass multiple pointers (or references) to a function. A concrete example would be passing overlapping memory ranges to memcpy instead of memmove. Actually, Rust’s memcpy equivalent is unsafe too, but that’s because it takes pointers instead of references. The linked page shows how you can make a safe swap function using the guarantee that mutable references never alias.

A more contrived example of reference aliasing is like this:

int f(int *x, int *y) { return (*x)++ + (*y)++; }
int i = 3;
f(&i, &i); // result is undefined

You couldn’t write a function call like that in Rust because you’d have to take two mutable borrows of the same variable.

More Related Contents:

  1. Why can’t I store a value and a reference to that value in the same struct?
  2. What are non-lexical lifetimes?
  3. The compiler suggests I add a ‘static lifetime because the parameter type may not live long enough, but I don’t think that’s what I want
  4. How can I create my own data structure with an iterator that returns mutable references?
  5. Lifetime error when creating a function that returns a value implementing serde::Deserialize
  6. Why does linking lifetimes matter only with mutable references?
  7. Why is adding a lifetime to a trait with the plus operator (Iterator + ‘a) needed?
  8. Cannot infer an appropriate lifetime for autoref due to conflicting requirements
  9. When is it useful to define multiple lifetimes in a struct?
  10. Lifetime troubles sharing references between threads
  11. Moved variable still borrowing after calling `drop`?
  12. What is lifetime elision in very simple terms?
  13. “borrowed value does not live long enough” when using the builder pattern
  14. How can this instance seemingly outlive its own parameter lifetime?
  15. How do I specify lifetime parameters in an associated type?
  16. How to operate on 2 mutable slices of a Rust array?
  17. When returning the outcome of consuming a StdinLock, why was the borrow to stdin retained?
  18. Why does my variable not live long enough?
  19. Why is the bound `T: ‘a` required in order to store a reference `&’a T`?
  20. Sharing a struct with trait objects as properties across threads
  21. Why can’t I return an &str value generated from a String?
  22. Type mismatches resolving a closure that takes arguments by reference
  23. How to fix lifetime error when function returns a serde Deserialize type?
  24. Extend lifetime of variable
  25. Why does the Rust compiler request I constrain a generic type parameter’s lifetime (error E0309)?
  26. Is it possible to control the size of an array using the type parameter of a generic?
  27. Does println! borrow or own the variable?
  28. Why is it possible to implement Read on an immutable reference to File?
  29. How to end a borrow in a match or if let expression?
  30. Why does creating a mutable reference to a dereferenced mutable reference work?

Leave a Comment