&, &mut, shared_ref, unique_ref

Is it correct to think of:

& as shared_ref
&mut as unique_ref

and we can write to something if and only if the entire "access chan" is all unique_ref and no shared_ref ?

If not, what is a counter example of where this breaks down ?

Yes, assuming no further meaning that you're pulling from somewhere else like another language.

It breaks down in the face of shared mutability, aka interior mutability.

And pedantically in the face of ownership, since you don't need a &mut String to overwrite a String you own, say.

2 Likes

Good call. Besides ownership & Cell/RefCell/Mutex/RWLock, are there any other exceptions?

I wrote a short article about this a few years ago:

https://limpet.net/mbrubeck/2019/02/07/rust-a-unique-perspective.html

2 Likes

Atomics, OnceCell, anything else utilizing UnsafeCell.

You can write through raw pointers like a *mut T too (unsafely).

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.