A potential rephrasing for chapter 4.1

[swift-hermes-1]

First of all, I love the book so far! It is clear and concise, which ultimately helped in me catching a potential inconsistency. Please correct me if I'm wrong!

The paragraph in question is one of the later ones, under the subtitle "Return Values and Scope". I quote:

"The ownership of a variable follows the same pattern every time: Assigning a value to another variable moves it. When a variable that includes data on the heap goes out of scope, the value will be cleaned up by drop unless ownership of the data has been moved to another variable."

The current wording suggests that move semantics apply to every assignment; however, the previous code example explicitly demonstrates that ´i32´ types are copied rather than moved.

fn main() {
    let s = String::from("hello");  // s comes into scope

    takes_ownership(s);             // s's value moves into the function...
                                    // ... and so is no longer valid here

    let x = 5;                      // x comes into scope

    makes_copy(x);                  // Because i32 implements the Copy trait,
                                    // x does NOT move into the function,
                                    // so it's okay to use x afterward.

}  // Here, x goes out of scope, then s. However, because s's value was moved,
   // nothing special happens.

Have I understood it correctly that there is a contradiction there? A proper rephrasing could in that case be something like:

"The ownership of a variable follows the same pattern every time: assigning a value to another variable moves it (unless the type implements the Copy trait). When a variable that includes data on the heap goes out of scope, the value will be cleaned up by drop unless ownership of the data has been moved to another variable."

While I understand the book introduces different concepts at different stages, the concept of the Copy trait was introduced just prior to this section. Because the text says it follows this pattern "every time," it seems to contradict the behavior of Copy types just established.

[StefanSalewski]

I can remember that I was not too happy two years ago with that phrase when I started learning Rust. It was more or less clear, but not well formulated. I am not sure is your modification is a big improvement. I finally decided to phrase it completely different in my book, see https://rust-for-c-programmers.com/ch6/6_2_transferring_ownership_move_copy_and_clone.html. What do you think?

[swift-hermes-1]

I think your version is quite straightforward. However, I also recognize the difference in target audience: the Rust book adheres to all learners of the language, whereas your book targets people knowledgeable in C.

A complete rephrasing in the Rust book aligning with yours would mean concepts presented in later chapters are moved forward to chapter 4. I think there might be pedagogical reasons that result in the book's structure, that unfortunately leads to some oversimplifications—or "white lies"—to help with accepting the main concept of moving, and pave the way for the next sub-chapter about references.

[StefanSalewski]

I think your version is quite straightforward.

Thanks for proof reading -- actually it was my intention to proofread the whole book myself this winter, but I have the feeling that will not really happen -- I am too lazy, and there is not much I could really improve.

For the target audience: That is actually not that different for the official tutorial book and my book. My book admits that it is not for complete beginners, and that some minimal knowledge of systems programming is helpful. While the official tutorial tries to address a very wide target audience, but still can be hard to understand for people with no programming experience or only some basic python history. My feeling was, that the verbose parts helped beginners not that much.

For your modified text section: Your modification is mostly the addition of the bracket "(unless the type implements the Copy trait)." First: It is generally a good writing style to avoid bracket expressions in a text -- beginners use typically too many, experienced writers only very few. And in this position, does it really help the reader? The reader would have to remember what is the "Copy trait" and what are copy types. Well -- I would have to read that full section of the book to decide if your bracket addition is really helpful. Personally I had two years ago the feeling that the text was quite clear, just not too well formulated. Personally, when in doubt, I tend to add the word "typically" or "generally" when a phrase is mostly true, but there are exceptions. So perhaps

"Typically the ownership transfer of a variable follows this general pattern: Assigning a value to another variable or passing that variable to a function moves it, unless the variable implements the Copy trait. When a variable that includes data on the heap goes out of scope, the value will be cleaned up by drop unless ownership of the data has been moved to another variable."

But well, such improvements attempts are difficult. Typically one has to read the context as well. "by drop" is not really nice as well. And the term "cleaned up" might be not fully clear as well. Was is defined earlier? The implemented drop trait will not only release heap allocated memory, but might do other resource cleanup as well, e.g. closing files.