Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

spotlesscoder
Copy link

No description provided.

Copy link
Contributor

@chriskrycho chriskrycho left a 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!

@spotlesscoder
Copy link
Author

That was a really good explanation - I think I finally really understood some aspect of the ownership system now.
I like your idea.

Maybe we could also add this sentence from your explanation?

In idiomatic Rust, functions do not take ownership of their arguments unless they have a reason to.

because that also wasn't clear to me until you mentioned it

@ghost
Copy link

ghost commented Oct 25, 2024

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.
As chriskrycho said, reference should be the default, and move should be the exception (if there's a reason).

@spotlesscoder
Copy link
Author

That was a really good explanation - I think I finally really understood some aspect of the ownership system now. I like your idea.

Maybe we could also add this sentence from your explanation?

In idiomatic Rust, functions do not take ownership of their arguments unless they have a reason to.

because that also wasn't clear to me until you mentioned it

@chriskrycho what's your opinion on that?

@jpmelos
Copy link
Contributor

jpmelos commented Nov 2, 2024

In idiomatic Rust, functions do not take ownership of their arguments unless they have a reason to.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants