> Passing data to a function when it's not a reference means that you're giving ownership to that function.
Only in Rust, but there's no apparent reason to move ownership. If Rust didn't move ownership during pass-by-value, it would still be trivial to prove the following code correct:
fn main() {
let x = String::new();
foo(x);
bar(x);
// x is destroyed
}
> Maybe I'm misunderstanding the problem you're having. Do you have an example of another language that lets you do what you want?
Here's the equivalent in C++:
int main() {
std::string x = "";
foo(x);
bar(x);
// x is destroyed
}
If those two functions both need to own the data you're passing in, then they should take it by value, because in Rust passing by value means giving ownership of the data to the thing you're passing it to. It might give it back (as a return value), but that's another matter.
If a function only needs to use some data for a bit, it should borrow it i.e. pass by reference.
And if you need to give ownership of some data to a function, and you also need that data for something else, you have to copy it, so that you can give one copy to a function to do what it wants with, and keep the other one for your own purposes.
Ownership of the String is moved and the original variable cannot be used until it is reinitialised, it is not copied. Pass by value is literally always a shallow byte copy in Rust (not following pointers) and the Rust compiler must disallow further use of many variables to ensure safety.
Rust doesn't have syntax for passing by value vs passing by reference. The syntax you're thinking of is instead for lending vs moving, e.g. moving `Box<T>` is still passing values by reference (but owned), and `&str` is a small copyable struct passed by value (but borrowed).
It's not the surprise-copy-horror you'd expect, because there are no copy constructors, and nothing large is ever copied implicitly (you have to call `.clone()` or implement `Copy` trait for a type).
The move semantics can ensure there exists only one owning pointer to each object. It can be statically known who owns the object, and most importantly, who has to free it.
> I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again.
By default the value is moved in Rust, just like with std::move in C++17, which you say you know. This is to avoid performance issues when you pass complex structures, such as vectors, around. If you want to copy your value, you have to call .copy() explicitly.
In the case of Rust it would typically be an immutable reference (or else passing by value wouldn't be an alternative). So the caller would have no reason to make a copy.
The way I think about this (which isn't quite how rust seems to) is that every value (including references) is always destroyed by passing it to a function, but gets implicitly copied if (arg is copyable && arg is referenced below). Eg:
T a = mkT() # create value
foo(&a) # create and immediately destroy/pass reference
bar(a) # => bar(copy(&a)) # create-and-pass copy
baz(a) # last use, so dont bother copying
For noncopyable values, this makes perfect sense; the callee got a value, so that value must have been moved out of the caller's variable. Treating copyable values the same way modulo the existence of a (T const ref -> T) copy function is just good consistency/orthogonality.
In this video[0] on Rust, in this example I was unable to directly tell whether the Vec structure is being copied to the take() function. If ownership is being handed over, why is a copy being made? And if a copy really isn't being made, then why aren't the function signature and the calling site reflecting that?
I hope I am making any sense... Please tell me if I should try to rephrase, or if I am in need of clarification on the subject.
(BTW, this is also something I really dislike about C++, two function calls that look exactly the same, foo(x) and bar(x), could either be pass by value or pass by reference: you have to go dig up the function signatures to figure that out).
is always destroyed by passing it to a function, but gets implicitly copied if (arg is copyable && arg is referenced below)
I am not sure what you are trying to say. This:
bar(a) # => bar(copy(&a)) # create-and-pass copy
baz(a) # last use, so dont bother copying
is not possible in Rust if a's type is not a copy type. a will be moved when calling bar, so trying to pass it to baz will result in a compiler error.
The story is quite simple: a value is always moved in a function call, unless it is a copy type (the type implements the Copy trait). When the type is a copy type, a bit-wise copy is made. References are not special: immutable references are copy types. Mutable references are not copy types (otherwise, they could be aliased).
You can find an overview of all copy types in the standard library in the implementations section of the Copy trait:
> A Box<dyn Bird> is some sort of Bird on the heap.
No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference").
> then my call moves the Box<Goose> into the function, I don't still have that Goose
Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
Whilst there are differences, that's not one of them. What decides whether the caller still has something is whether you passed it by reference.
fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed)
fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells.
fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked.
† If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.
Contrast with Rust references, which are very much their own type (they more resemble pointers in their behaviour, with explicit dereferencing and address-of needed). As a C++ dev, this took some getting used to! But I never was a fan of how passing-by-reference was invisible at the call site.
> Even if those values contain owned references into the heap, the programs can be trivially proven to be correct.
I don't think that's true. Passing data to a function when it's not a reference means that you're giving ownership to that function. How could you then pass it to another function (unless the first returned it again)? Once a function has ownership, it means nothing else has ownership of the data.
Basically, if you write a function that just takes a value, and doesn't take a reference, then you're telling your callers to give you ownership. If you don't want to take ownership, then just always accept a reference.
Maybe I'm misunderstanding the problem you're having. Do you have an example of another language that lets you do what you want?
Because when you pass by reference, you lend the value (or to phrase it the other way around: the function borrows the value). And so when the function’s done, it gives you the value back (because that’s how borrowing works, in the everyday sense of the word, as well as in th Rust sense)
> Is the borrow syntax (&x) a reference while vanilla (x) is by value? Or are both passed by reference but with different ownership affects?
This is briefly addressed in the FAQs:
"What is the difference between passing by value, consuming, moving, and transferring ownership?
These are different terms for the same thing. In all cases, it means the value has been moved to another owner, and moved out of the possession of the original owner, who can no longer use it. If a type implements the Copy trait, the original owner’s value won’t be invalidated, and can still be used."
"The stack is very fast, and is where memory is allocated in Rust by default."
"What do other languages do?
Most languages with a garbage collector heap-allocate by default. This means that every value is boxed. There are a number of reasons why this is done, but they’re out of scope for this tutorial. There are some possible optimizations that don’t make it true 100% of the time, too. Rather than relying on the stack and Drop to clean up memory, the garbage collector deals with the heap instead."
So unless your data structure is boxed, it's allocated on the stack and passed by value and different ownership effects apply as well.
> I got hung up the other day on passing a String to a function that accepted &str which someone explained to me Strings dereference to &str but I think I just ended up more confused.
String literals de-sugar to &str. E.g.,
fn borrow_str(s: &str) {}
borrow_str("foo"); // This works
borrow_str(String::new()) // this doesn't work
fn take_str(s: String) {}
take_str("foo") // Doesn't work
take_str(String::new()) // works
take_str("foo".to_owned()) // works
in JavaScript, one is just using the variable name as a "holder" of some value. One doesn't have to designate that that variable is being passed by reference. If one wanted to actually copy that object, they'd have to devise a mechanism to do so. In Rust, if someone doesn't specify, using the & symbol, that something is a reference, it'll end up moving the value.
Basically all I was saying is one can not approach writing Rust with a Java/JavaScript mindset. (That a variable is just a bucket holding a value). Care needs to be taken when referencing a variable as it may need to be moved, copied/cloned or referenced. In the case of copying, another memory allocation is done. So if someone approaches Rust from the standpoint of "this word represents a value, and I'm going to use it all over the place", they can find themselves blindly allocating memory.
And the references are passed by value. There are two places you can find in RAM that will contain that reference, which once you penetrate through the abstractions and wrappers, will be a pointer; that second location is the reference that was passed by value. A reference is basically a pointer that the language prevents you from doing pointer arithmetic on, and in many languages such as PHP, is simply automatically dereferenced for you.
The reason why I brought up languages like Forth is that there really did used to be languages that did not actually "pass" things by value. Forth had a true pass-by-reference, in which there is no second copy of anything, neither the value, nor a pointer to the value. Now it's a dead distinction, in the sense that pass-by-value and pass-by-reference used to be distinguishing, because everything is copying something. Which is why the distinction is sort of confusing to try to apply to modern languages, and produces lots of heat but no light; it's dead, inapplicable to the modern language landscape.
The proper question to be asking is what permissions/privileges are passed by a function's parameter, whether you're allowed to modify it and have the modifications visible to the caller, whether you're not allowed to modify it at all (immutable languages, for instance), or whether there's an entire ownership system around what the passed-in value represents (Rust), not whether or not something was copied when the function call was made. Trying to answer this question in terms of "pass-by-X" doesn't help, if for no other reason than pass-by-X implies there's only two possibilities, and I outlined three classes of possibilities above, each of which can have their own further nuances. Is Rust pass-by-reference or pass-by-value? Well, the question is invalid, in either the original or the modern mutation of the meaning.
Interestingly, the type of `x` actually does matter here in Rust! For most types, yes, passing something by value into a function will cause the memory to be "moved", which means that reusing `x` will be a compiler error. That being said, you can also either pass a shared reference (i.e. `&x`), which will allow you to access the data in Rust (provided you don't move anything out from it or mutate it, which would cause a compiler error) or a mutable reference (i.e. `&mut x`), which will allow you to access or mutate the data in `x` but not take ownership of it (unless it's replaced with something else of the same type).
However, a few types, including integers, but also things like booleans and chars, implement a trait (which for the purposes of this discussion is like an interface, if you're not familiar with traits) called Copy that means that they should be implicitly copied rather than moved. This means that in the specific example you gave above, there would not be any error, since `x` would be copied implicitly. You can also implement Copy on your own types, but this is generally only supposed to be done on things that are relatively small due to the performance overheard of large copies. Instead, for larger types, you can implement Clone, which gives a `.clone` method that lets you explicitly copy the type while still having moves rather than copies be the default. Notably, the Copy trait can only be implemented on types that already implement Clone, so anything that is implicitly copied be can also be explicitly copied as well
C++ reference types are first-class. But instances of reference types are not first-class values. References are not objects, in standard speak, they do not have a memory location, you can't take their address, you can't pass them to functions (a reference parameter means passing a value by reference, not a reference by value). And so on. Rust references are more like C/C++ pointers or Java references in that they are actual values, and AFAIK Rust functions, like Java and C functions, are strictly pass-by-value.
Only in Rust, but there's no apparent reason to move ownership. If Rust didn't move ownership during pass-by-value, it would still be trivial to prove the following code correct:
> Maybe I'm misunderstanding the problem you're having. Do you have an example of another language that lets you do what you want?Here's the equivalent in C++:
reply