fix: make the reason more understandable

[spotlesscoder]

No description provided.

[chriskrycho]

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]

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]

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]

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]

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.

[chriskrycho]

I agree that it would be handy to have that heuristic in the book somewhere! @spotlesscoder if you want to update the PR so it reads something like this, I’d be happy to see it land:

The first_word function has a &String as a parameter. We don’t need ownership, so this is fine. (In idiomatic Rust, functions do not take ownership of their arguments unless they need to, and the reasons for that will become clear as we keep going!) But what should we return? We don’t really have a way to talk about part of a string. However, we could return the index of the end of the word, indicated by a space. Let’s try that, as shown in Listing 4-7.

[chriskrycho]

Thanks! I’ll merge this once it runs through CI and is ✅!