well, ugh. I don't know what best practices here are. I went ahead and shared addresses fairly freely. what I didn't share is ownership/deallocation responsibility.
Conversation
what I mean is, I have no idea how I could create a working compiler without letting people borrow addresses/references all over the place. however, I made sure that all borrowers either made a copy or else forgot about what they had borrowed.
2
4
Replying to
Agreed.
Lots of interest in Rust's typesystem enforcing that specific behavior (forget or copy). How hard was it to maintain this discipline in C++ without that check?
2
3
Assignment, passing and returning in Rust works like C rather than C++. It has move semantics by default. If you try to use it after it was moved, you get an error and realize you need to either add a call to clone() or use a reference, and it prevent using dangling references.
1
2
In Rust, you end up using drastically more moves than in C++ along with substantially more lightweight references.
So, for example, using Rc<T> (thread-local shared pointer) or Arc<T> (cross-thread) in Rust is way cheaper because you use drastically more moves / references.
1
1
You have to implicitly call clone() to increase the reference count and you would only do that when you have to rather than it being the default and natural. The way you end up writing code is much different, *especially* with heavy use of views of vectors and strings.
1
1
This sounds a lot like deleting the copy constructor and assignment.
Let's implement:
-fno-copy-construction
that disables copy-constructor and assignment for full Rust experience.
1
Moving is an implicit default in Rust.
The important part is it's all memory safe due to the compiler preventing using anything after the lifetime ends.
It tracks the lifetime of references as part of their type to prevent using them beyond the scope of what they reference.
1
It also has to implement rules for aliasing. The general rule is that the usable mutable references (&mut) can't overlap. Normal immutable reference (&) can overlap. In terms of memory dependencies, references don't alias.
1
If you take deeper mut references, can't use the outer ones until those are gone. The language and libraries are designed around having lifetime checks and aliasing checks. Lifetime and aliasing rules also end up being the basis for not having data races, alongside Send / Sync.
1
The reason why Rc<T> doesn't need to use atomic reference counting is that it's non-Send, unlike most other types, so it can't be sent to another thread. There's a similar concept of Sync for whether &T can be shared across threads. RefCell is non-Sync, RwLock/Mutex are Sync.
Most types are both Send and Sync. These things are integrated into the language. The most complex piece of it is the borrow checking system enforcing the lifetime and aliasing rules. It's easy to understand the concepts it implements but it's far from trivial to implement it.