Struct update syntax doesn't reborrow mut references about rust HOT 4 OPEN

@rustbot label -needs-triage +T-lang -C-bug +C-discussion

Not sure if this is a bug because this is clearly documented (https://doc.rust-lang.org/book/ch05-01-defining-structs.html):

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. ... 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.

from rust.

I think "clearly documented" is overstating it a bit. I've read the documentation you linked before filing this and I found that in this case it wasn't conclusive. In particular:

Note that the struct update syntax uses = like an assignment; this is because it moves the data

The implication is "therefore you can use the fields anymore unless they're Copy", but it seems like "you can't use the fields anymore unless they're Copy or can be reborrowed" would be a valid interpretation too.

This part especially:

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.

Implies that the struct itself isn't moved, fields are moved, and the struct is still valid if the only field accessed can be moved without invalidation. The doc mentions Copy, but it doesn't explicitly opts out of reborrowing.

(Yes, I'm splitting hairs on all this. My more down-to-earth takeaway is that, as an end-user, this feels more like a corner case not being handled than a new feature not being added yet.)

from rust.

Ah sorry, yeah I agree it's quite inconclusive for this particular case. Hope someone more experienced with the language semantics can help sort it out for you.

@rustbot label +C-bug

from rust.

As @scottmcm has noted before, the current semantics for the "functional record update" syntax... the JS programmer in me wants to just call it "spread syntax", tbh... are actually Quite Bad, and should probably be more intuitive (in the sense of "they should work more like a move/reborrow"... a destructure, then a restructure, I guess?). I believe this is consistent with the current bad semantics, however.

from rust.