Improve description of access to Struct instances when a field is moved

[tschier]

Chapter 5.1 has this paragraph:

Note that the struct update syntax uses = like an assignment; this is because it moves the data, just as we saw in the “Variables and Data Interacting with Move” section. In this example, we can no longer use user1 as a whole after creating user2 because the String in the username field of user1 was moved into user2. If we had given user2 new String values for both email and username, and thus only used the active and sign_in_count values from user1, then user1 would still be valid after creating user2. Both active and sign_in_count are types that implement the Copy trait, so the behavior we discussed in the “Stack-Only Data: Copy” section would apply. We can still use user1.email in this example, since its value was not moved out.

As a newcomer, these three portions weren't easily reconcilable:

we can no longer use user1 as a whole

This may be read as "neither user1 itself nor any part of user1 is accessible."

Both active and sign_in_count are types that implement the Copy trait, so the behavior we discussed in the “Stack-Only Data: Copy” section would apply.

That section doesn't describe behaviour in the context of structs (i.e. that those fields are still accessible).

We can still use user1.email in this example, since its value was not moved out.

This seems to contradict the first line above, that the whole over user1 is not able to be used

I propose that the book should explicitly call out that access to user1 and its fields is not straightforward. Direct access to the user1 instance is no longer valid as one or more of its fields have been moved; but that access to any of the fields that have not been moved (because they implement Copy) is still valid.

[StefanSalewski]

Thanks for reporting. I am not sure if the text of that section really have to be improved, but the following is really interesting:

We can still use user1.email in this example, since its value was not moved out.

I totally missed that when I read that book in October 2023. Actually, moving fields of a struct in an interesting topic in general, I never thought about that, I will have to verify that in my own Rust book.

[EDIT]

I just had a look at the book of the Brown university: https://rust-book.cs.brown.edu/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax. That explanation is a bit different and more what I remember. So my guess would be that this behavior might have changed in the last 18 months?

[tschier]

I'm new to Rust so can't comment from experience regarding the last 18 months.

The blame on Chapter 05-01 shows this edit from 3yrs ago. In that edit the ... as a whole addition could be an attempt to explain this behaviour, in which case it wouldn't be new.

At any rate, as you say moving fields of structs, and understanding what is still valid in the enclosing struct instance is an "interesting" topic, and IMHO it's at least worth flagging the interestingness to newcomers.

[StefanSalewski]

Sorry, I am also relative new to Rust (started in October 2023), and I am a bit confused about this topic of moving struct fields. I think I actually misunderstand it initially in the way that moving one field out of a struct would invalidate the whole struct, which seems to be wrong. I was once playing with a similar use case -- having a vector of strings, and moving one element into another variable. I think that was just an invalid operation. Moving struct fields is even more interesting. I will try to learn more about this topic and fix the description in my own book -- perhaps I should ask in the Rust forum.

A related Forum post is https://users.rust-lang.org/t/invalidation-of-struct-after-moving-one-of-its-attributes/77939 but it gives not much new information.