Hacker News Reader

Comment by _nalply | Hacker News Reader

I read somewhere that immutable and mutable borrows are perhaps alternatively understood as exclusive and shared borrows.

This means, if you have a &mut then you have an exclusive borrow. No other borrows are possible as long as your &mut lives (i. e. did not yet go out of scope). Usually this exclusive borrow is used for mutating values.

This dichotomy in terminology is shown when you learn about interior mutability. Here you can mutate values without having an exclusive borrow, an example is RefCell. The price you pay for this convenience is run-time checking of access. RefCell disallows mutation if some other location in your code already has asked for mutable access.

View on HN

I read somewhere that immutable and mutable borrows are perhaps alternatively understood as exclusive and shared borrows.

Yes, when it comes to exterior mutability, it's basically single mutable xor multiple immutable.

The price you pay for this convenience is run-time checking of access.

The nice thing is that RefCell is not magic, it's Rust all the way down. E.g. the status of the borrow is updated by the destructors (Drop) of the reference types. All administration is done using a signed integer to do reference counting. The value 0 means 'no borrows', any positive number indicates the number of immutable borrows, -1 means one mutable borrow.

It's well worth reading the implementation of RefCell some time!

> The nice thing is that RefCell is not magic

I'd like to point out that `RefCell` does contain a bit of magic, since it is based on `UnsafeCell`, which is _the_ core "primitive" of Rust that enables interior mutability:

https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html

(Not trying to be pedantic, just to clarify things for less knowledgeable readers).

I assume the parent meant that there was no compiler magic at play, as far as I know UnsafeCell is written in pure Rust, just using unsafe code: https://doc.rust-lang.org/src/core/cell.rs.html#1486-1488

So basically if Rust's stdlib didn't provide it, you could reimplement it yourself from scratch.

EDIT: actually, reading the comments, it looks like I'm wrong about that:

> If you have a reference `&SomeStruct`, then normally in Rust all fields of `SomeStruct` are immutable. The compiler makes optimizations based on the knowledge that `&T` is not mutably aliased or mutated, and that `&mut T` is unique. `UnsafeCell<T>` is the only core language feature to work around the restriction that `&T` may not be mutated.

I'm not sure that's correct. `UnsafeCell` is a Rust lang item that might disable some optimizations, I think?

https://doc.rust-lang.org/src/core/cell.rs.html#1483

You're right, I just saw that. Well I least I learned something new about Rust today!

Yep, you can't implement UnsafeCell yourself without running into undefined behavior.

WRT your edit:

  #[lang = "unsafe_cell"]

This tells you that UnsafeCell is a Language Item[1], which basically means that the compiler does have knowledge of it.

[1]: https://doc.rust-lang.org/beta/unstable-book/language-featur...

This annotation let's the compiler treat their items in special ways, but it is usually for either easier way to refer to them (I want to desugar this type to a cell of what I already have) or for diagnostics. I think box is one of the few "magical" things in the language.

Sorry, I should have been clearer about that. You are completely right that at some point things have to rely on some primitives that are 'magic' (in this case UnsafeCell). But I meant that RefCell itself uses standard constructs to guarantee the 'single mutable xor multiple immutable' invariant.

This line in the Rust book is what made it click for me: "Rust can figure out definitively whether the method is reading (&self), mutating (&mut self), or consuming (self)."

This was from the methods chapter but I think it applies globally. You either borrow to read, borrow to mutate, or consume (and possibly return a different value back)

I'm sure there will be more nuance but I think this is a good conceptual foundation to begin with.

What does 'consume' mean in this context?

The function "consumes" the value. Its no longer valid in the function caller's scope.

Often the purpose is to consume the value and return a new kind of value. Maybe `validate_square` takes in `Shape` and returns `Option<Shape>`

If valid or invalid, we have consumed the shape so it cant be reused by accident and can't be used without handling the optional branches.

I'm new so maybe I'm off on this.

In Rust, this is how “ownership” works. Once a variable is moved to a new scope, ownership moves with it, which means that it cannot be used in the current scope anymore.

"Consume" is comparable to a "move" in C++.

If I consume your apple then you no longer have your apple and the apple will be gone once I finish with it. But because I eat apples whole, I can spit it out before I swallow and return it to you.

The analogy may not be perfect but the point is complete control of the object has been transferred to the function and so you no longer have access to it and it will be destroyed once the function ends, unless it's returned.

I always liked to think of it in terms of car ownership. You can immutably borrow my car (&car) but if you modify it, you're a jerk (you obviously can't modify it in Rust). Or if you're a mechanic you can mutably borrow (&mut car) it and upgrade it or something. Orr, if I sell my car to you, you've taken ownership of it.

fn borrow_car(car: &Car); fn modify_car(car: &mut Car); fn sell_car(car: Car);

Obviously there'd be other parameters in the functions, but yeah that's the gist of it.

It is equivalent to "pass by value and that binding is no longer valid after the call".

Well said.

Rust's terminology is kind of reversed: It is stated that a mutable reference cannot be shared, while in fact a reference is called "mutable" when it cannot be shared.

The terminology is understandable and great to get started, but once you dive in deeper into atomics and internal mutability, it's rather crucial to understand this reversal.

I suppose you can think about it as having a shared borrow to the ref cell, but using it to gain an exclusive borrow to the data underneath, to fit the intuition.

You might find this interesting. It's about C++, but it's a very similar take:

https://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutte...

Reply on news.ycombinator.com