Hacker News Reader

Comment by chlorion | Hacker News Reader

There is nothing broken in this example, it's functioning exactly as it's intended to. What makes you think the borrow checker is broken here?

It appears like you don't really understand the rule about mutable and immutable references. Asking for the length of the vector requires an immutable reference, but you already have a mutable reference, which is explicitly not allowed by design (that's the whole point!).

So, you can only have one mutable reference to something if there are no immutable references, and multiple immutable references if there are no mutable references, you can never have both immutable and mutable references to something at the same time.

View on HN

I don’t know Rust, just wondering: why is it forbidden to know a length of vector to which you hold a mutable reference? What could go wrong?

I imagine you can have one thread modifying the vector while trying to read its length from another thread.

Noone should imagine that. You definitely don't want two threads accessing the same vec or array at one time. Maybe if there's a lock

If it's read only, you can definitely want that, right? As long as the elements are Sync. And it should work (You might have a problem with the cleanup, but Arc or scoped threads should handle that). The problem is when one is a mutable reference, like in this case. AIUI you could have a single mutable reference to an element be used from another thread (For example, a scoped thread) if the elements of the Vec are Sync

The problem is not “a length of a vector”, Rust is not that fine grained. As far as Rust is concerned, what can happen is that you acquire an immutable reference to an object while there’s a mutable (unique) reference outstanding, you can invalidate the immutable reference via the mutable one, and thus have a dangling reference, which is UB.

Hell, even here one could imagine two scoped threads (so they can work with references), one thread keeps modifying the vector, and on some ISAs the other might get torn values for the length, or possibly worse (I don’t know if worse is an option but I wouldn’t be surprised).

OP is just holding a reference to a single entry in the vector. You could write whatever you want to that entry, but it's not going to change the length of the vector. In some sense the problem is that Rust is not "fine grained" enough to figure out that OP's access pattern is valid.

It's not just about that. What rust sees is you are calling two functions: the len() function with a shared reference, and the indexing operator implementation for the Vec's [] (Which is just a function) with a mutable reference, which returns a mutable reference. The compiler does not look at the actual implementation of these 2 functions to figure things out, it only looks at the signatures (If it did look at the implementations, it would probably be slower, and what's worse, the caller's code could stop compiling if you change the implementation! That would be specially bad across a library boundary). The implementations are irrelevant AIUI to the borrow checker, only the signatures matter.

I'm taking a reference to the array the vec is pointing to not the vec. Rust needs to be more fine grain because it's obnoxious and C++ container invalidation is less bad https://news.ycombinator.com/item?id=32188672

Reply on news.ycombinator.com