I kept reading about the move semantic and something interesting came up: I applied what I wanted to see in my other post and was given similar code from a "move" to a ref (which is what I vouched for, so it's nice):
You may uncomment one or the other of the main and see that we have about the same result.
That code does nothing meaningful (obviously), nor is it doing anything in a smart way, it is just me playing around and discovering.
Now the question, and a call to your experience to confirm/infirm the scheme I am currently drawing in my head: since we will have a multi threaded code that don't share structures between the threads, making each threads effectively isolated, is there a danger I don't measure yet to always pass "by move" instead of by "&mut" ?
Any hurdles with crates to expect ? The code will be kept in-house so we don't really care about making it look good to others.
I prefer that syntax and really feel better coding that way in Rust (specifically).
It is not inherently more "dangerous" to pass by value or by reference. (Since the type system guarantees thread safety and the unicity of mutable references, the usual caveats you'd need to be aware of in other languages simply don't apply in Rust.)
Whether you pass by value or by reference must not be dictated by upfront assumptions as to which one will
"work better with libraries" (I don't even think that's a meaningful question to ask). It should be decided based on the inherent structure of your data and the operations you want to perform on it.
I is meaningful because I don't master the borrow checker and other moving parts, so yes, it is good to make sure I don't put my intent in trouble because of a short-sightedness of any kind.
The main difference between the two patterns is what happens when the function panics. In the &mut case, it is guaranteed to leave a valid vector behind the mutable reference, whereas the move version will destroy the vector on panic.
Ah!
Yes, that a good reason to be careful; I will double check that but the functions are mostly geared toward calculations, not too many I/O access. And divisions and overflows are taken care of BTW (it's basically converting existing and functional code at this point).
This is why you can't call a move based method with a value stored behind a mutable reference. Since you only have a mutable reference, you must leave a value behind if you panic, but the move based method will destroy it if it panics.
One workaround is to store a dummy value in the mutable reference (e.g., an empty vector) for the duration of the call to the move based method, and then overwrite it with the result afterwards. This way, you leave behind the dummy value on panic.
No, that's not the point (or even a correct conclusion). Values owned by a function that panics will be cleaned up properly. The point is that this is why you can't just move out of a reference.
