-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: make the reason more understandable #4074
base: main
Are you sure you want to change the base?
Conversation
8ef3399
to
26f571b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion. However, there are many reasons we might want to not take ownership; the point is not that this code has one specific reason not to take ownership but that it has no specific reason it does want to take ownership. In idiomatic Rust, functions do not take ownership of their arguments unless they have a reason to.
-
Taking ownership means they now need to manage returning it or dropping it, which is something you really only want to do when you have a specific reason to.
-
If a function can just borrow the data, the function itself has less to manage, and its contract is much clearer to callers. For example, with a function which takes
&String
like this, you know that it will at most read the string.
By contrast, if you have this signature:
fn in_and_out(s: String) -> String;
You know absolutely nothing about what happens with s
, except that it is moved into the function. Does s
get mutated and then returned, or some other string constructed from it, or is there an unrelated String
produced for some other reason? 🤷🏻♂️ Who knows! Nothing relates the two in any way.
This is not really the spot to explain all of that, though! As I said in the corresponding issue:
We don’t want to try to stop and explain all of this at the point where the statement is made, because it becomes clear by continuing to read the rest of the section.
Likewise, the other ideas I mention here are covered in various ways elsewhere.
Again, I definitely appreciate why this was a slight sticking point. However, if we try to explain everything at every point in the book, it will become even huger than it already is.
I think there is a change we could make here which I think would convey some of these ideas with minimal disruption, though: if we swap out “want” for “need” it suggests many of these ideas without getting into the details. If you want to update the PR to do that, I will happily merge it!
That was a really good explanation - I think I finally really understood some aspect of the ownership system now. Maybe we could also add this sentence from your explanation?
because that also wasn't clear to me until you mentioned it |
Not moving because I want to use the object after the function call is a dangerous thought. It leads us to think (especially for a beginner) that if I don't want to use the object after such a call, the correct approach would be to move it. There are explicit reasons to want to move something. |
@chriskrycho what's your opinion on that? |
I just want to add my voice here that adding this somewhere in the book (I don't know if exactly where this PR is, but somewhere) is very useful. I am reading this book slowly and trying to really grok every concept, and I'm in chapter 16 now, and I don't think this "implicit rule" is mentioned anywhere. I think it's a very good rule and something that should be mentioned explicitly. |
No description provided.