No, the problem you describe does not exist in my implementation because it
requires an &mut to the smart pointer.
In particular, if the reference count is 1, then there is no other Rc and Arc
pointing to the same data, and because we have an &mut there is also no other
borrowed reference to the Rc or Arc we are manipulating.
Hence, if the reference count is 1 and we have an &mut to the Rc or Arc, it's
safe to return an &mut pointing to the contents and thus mutate its contents in
place using it.
If the reference count is more than 1, then it uses read-only access to clone
the contents, giving a new allocation with reference count 1 that can then be
mutated in place as above.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
