It would be better to differentiate between ownership and the O permission.

[CybCom]

When reading ch4.2 and ch4.4, I noticed this

References Are Non-Owning Pointers

That's quite reasonable. But when I get here

References Change Permissions on Paths

I found it confusing that if a ref is "non-owning", how can it get O permission and how does the initial variable lose it?

And I realized that the word "owning" in the first sentence is related to the concept of ownership, which decides when will the memory get freed. And the "Own permission" in the second paragraph, as literally shown, is related to permissions that the borrow checker works with.

When the ref(with O permission) ends its life, the O permission, which is borrowed, will be returned. But if the ownership is transferred, it will not be automatically returned.

So I think it would be better to add a short paragraph to differentiate between ownership and the Own permission. Is my understand and this idea correct? Thanks to anyone who concerns.

[willcrichton]

That's not quite the right way to think about it. In this example:

let x = 0;
let x_ref = &x;

x_ref has the O permission because you can use x_ref as if it were owned. You can say drop(x_ref) and Rust will not complain. However, you cannot say drop(*x_ref) (if x were a non-Copy type like String). That's the difference. I can try to make this clearer in the book.

[CybCom]

Got it, thank you. Hope some edit to the book will make the concept clearer.

[fktyf-13]

In the current version it is still very confusing. In ch.4.2 there is caption [References Are Non-Owning Pointers]. Though later references have O permission.