Skip to content

Commit 160bc44

Browse files
committed
Ch. 05: further tweak to wording about user1 availability
This is a tricky thing to get “just right”, and I am not *totally* happy with this solution, but I think it’s actually better without the “as a whole” given the addition of the sentence at the end indicating that its fields can still be accessed.
1 parent 5fe7297 commit 160bc44

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

nostarch/chapter05.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -214,9 +214,10 @@ on page XX. In this example, we can no longer use `user1` after creating
214214
`user2` because the `String` in the `username` field of `user1` was moved into
215215
`user2`. If we had given `user2` new `String` values for both `email` and
216216
`username`, and thus only used the `active` and `sign_in_count` values from
217-
`user1`, then `user1` would still be valid after creating `user2`. Both
218-
`active` and `sign_in_count` are types that implement the `Copy` trait, so the
219-
behavior we discussed in “Stack-Only Data: Copy” on page XX would apply.
217+
`user1`, then `user1` would still be valid after creating `user2`. Both `active`
218+
and `sign_in_count` are types that implement the `Copy` trait, so the behavior
219+
we discussed in “Stack-Only Data: Copy” on page XX would apply. We can also
220+
still use `user1.email` in this example, since its value was *not* moved out.
220221

221222
### Using Tuple Structs Without Named Fields to Create Different Types
222223

0 commit comments

Comments
 (0)