About ownership

#1

Hi,all

Why doesn’t the compiler issue an error at Line 15 while I am trying to assign it’s field with a new value ? It did throw a message at Line 16 saying p was moved at Line 14 already.

Snip20180427_2
Snip20180427_2.png948x840 60.8 KB

#2

Hi,

This section in the documentation is describing what is happening https://doc.rust-lang.org/book/second-edition/ch04-01-what-is-ownership.html#ownership-and-functions

Also a small hint. You can post code here without using screenshots by writing the code within these blocks

```
Code goes here
```

Cheers

#3

In this section, The Book also states that :

If we tried to use s after the call to takes_ownership, Rust would throw a compile time error.

I wander that why the compiler complains at Line 16 , not Line 15. Both use the moved variable p. I reassign p’s field x at Line 15 and the compiler doesn’t give a warning or an error. For the user’s perspective, Line 15 is useless if so. My question is: what does the compiler do when it comes to Line 15 ?

#4

The line 15 is a partial initialization. (Failing to find a doc link.) It isn’t used very often.

#5

I think you can use the following mental model: moving is essentially memcpy-ing the struct to the called function stack. (usually it’s optimized out, but initially it’s there) Memory region of old p is still there on stack, but is marked as “moved”, which makes it unreadable, but it does not forbid you from writing into that memory. Same story applies to this example:

let mut p: Point;
// works
p.x = 5;
// compilation error
println!("{}", p.x)

The only difference is that memory region of p marked not as “moved”, but as “uninitialized”. Although I agree that your example is strange and ideally Rust should produce error for line 15 as well. (of course if I am not missing some obscure cases where such behaviour will be useful)

#6

I have no idea what the use cases are; but IIRC if you assign all of the fields in this manner, Rust will consider the object to be fully initialized.

Just watch out for the terrifying soundness hole. (surprise, a feature that almost nobody uses has bugs!)

#7

Nope, it does not work like this unfortunately. It could be a nice (but arguably rarely needed) feature if Rust could’ve tracked partial initialization and detect if type became fully initialized.

#8

This is issue #21232.