Conversation

Patricia Aas

@pati_gallardo

May 13, 2021

I don’t know Rust, so I was wondering how this would look in C++, does anyone have an example?

Quote Tweet

Patrick Walton

@pcwalton

May 13, 2021

Conceptually, the thing that makes Rust different from modern C++ (and other languages) is the "alias xor mutable" guideline, enforced by the borrow check. You could write C++ that way, but in practice nobody does. It's much stricter than just using smart pointers.

Show this thread

Replying to

In Rust, you can only hold either one mutable reference or a bunch of immutable references to x. For example: int x = 42; x += 1; // ok const int& r1 = x; // ok x += 1; // Error const int& r2 = x; // ok int& r3 = x; // Error

Replying to

and

or int x = 42; int& r1 = x; // ok r1 += 1; // ok const int& r2 = x; // error int& r3 = x; // error This restriction roots out the possibility of race conditions. And as far as I know, no other major languages (not just C++) have enforcement in this way.

Replying to

This seems very strange to me… why would one guard things this carefully when they are not actually being shared?

Replying to

and

Across threads, I mean

Replying to

and

Mutable references can invalidate other references by freeing allocations, changing the variant in a tagged union, etc. The issue isn't only data races. So, for example, a mutable reference to a std::vector can push to it resulting in use-after-free via other references, etc.

Replying to

and

Similarly, a mutable reference to a tagged union (including very common ones in Rust like Option or Result) can switch Some(T) to None, etc. which would invalidate references. There are a lot of ways for a mutable reference to cause memory corruption via overlapping references.

Replying to

and

Rust has Cell (interior mutability) to cover cases where multiple mutable references are safe by using immutable references with a type that has a safe system for inner mutability known to the type system and compiler: doc.rust-lang.org/std/cell/struc &Cell<T> happily alias each other.

Replying to

and

RefCell<T> is just dynamic enforcement of the usual rules: any number of immutable references or one mutable reference. There are ways of splitting a mutable reference into multiple inner references via pattern matching, slice methods, etc. They just aren't allowed to overlap.

10:21 AM · May 13, 2021Twitter Web App

Replying to

and

So, for example, if you have &mut (int, int), you can trivially get a separate mutable reference to each integer. Similarly, you can split a mutable slice (&mut [T]) into two non-overlapping ones with split_at_mut along with other approaches. &mut T happily coerces to &T too.