Rewrite reference_wrapper.rs to be structs.

[adetaylor]

Building on researches explained here.

[Ravenslofty]

I was thinking about the article a bit, and it seems to be built on a somewhat incorrect foundation: that & vs &mut means aliasing XOR mutability when it means aliased XOR unique - mutation of a & reference is possible through UnsafeCell. Certainly, having an &mut reference and an & reference both from C++ code is UB, but C++ having some mutable reference to something in its code is fine if Rust only ever has an &UnsafeCell<T> or something that wraps UnsafeCell.

Thinking of how easy it would be to write a C++ function that hands out &mut references to, say, a singleton, part of me wonders if one has to banish &mut from C++ FFI and instead have &T vs &UnsafeCell<T> or something instead.

[adetaylor]

instead have &T vs &UnsafeCell or something instead

I agree you could use &UnsafeCell<T>, although I think you'd have to use that for all references, not just mutable references. AIUI the existence of a &T to anything that might mutate, with the sole exception of UnsafeCell, is UB.

In the end, then, &UnsafeCell<T> has similar properties to *mut T which is what we're currently using in these experiments. IMO, either way to make them ergonomic we need to wrap them in some sort of CppRef<T>, and that's where all the complexity lies because arbitrary_self_types is not yet stabilised. The actual internal implementation of CppRef<T> could easily change in future to &UnsafeCell<T> if advantages showed up.