aliasing rules also apply inside private fields#2304
Conversation
rustbot
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
aliasing-in-fields
branch
from
49af5a1 to
960da81
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
| * Breaking the pointer aliasing rules. The exact aliasing rules are not determined yet, but here is an outline of the general principles: | ||
|
|
||
| `&T` must point to memory that is not mutated while they are live (except for data inside an [`UnsafeCell<U>`]), and `&mut T` must point to memory that is not read or written by any pointer not derived from the reference and that no other reference points to while they are live. `Box<T>` is treated similar to `&'static mut T` for the purpose of these rules. The exact liveness duration is not specified, but some bounds exist: | ||
| `&T` must point to memory that is not mutated while they are live (except for data inside an [`UnsafeCell<U>`]), and `&mut T` must point to memory that is not read or written by any pointer not derived from the reference and that no other reference points to while they are live. `Box<T>` is treated similar to `&'static mut T` for the purpose of these rules. These rules apply to *all* references and `Box<T>`, including those inside private fields. |
There was a problem hiding this comment.
FWIW all I did is add a single sentence, and then break the liveness part into a separate paragraph. But the newline style makes that very hard to tell from the diff.
EDIT: The "rich" diff makes it fairly clear though.
EDIT2: Now that I did a few more minor edits, the "rich" diff has also fallen apart. In one-sentence-per-line style, the diff would still be very easy to interpret.
| * Breaking the pointer aliasing rules. The exact aliasing rules are not determined yet, but here is an outline of the general principles: | ||
|
|
||
| `&T` must point to memory that is not mutated while they are live (except for data inside an [`UnsafeCell<U>`]), and `&mut T` must point to memory that is not read or written by any pointer not derived from the reference and that no other reference points to while they are live. `Box<T>` is treated similar to `&'static mut T` for the purpose of these rules. The exact liveness duration is not specified, but some bounds exist: | ||
| `&T` must point to memory that is not mutated while they are live (except for data inside an [`UnsafeCell<U>`]), and `&mut T` must point to memory that is not read or written by any pointer not derived from the reference and that no other reference points to while they are live. `Box<T>` is treated similar to `&'static mut T` for the purpose of these rules. These rules apply to *all* references and `Box<T>`, including those inside private fields. |
There was a problem hiding this comment.
including those inside private fields
Hmm this could also be read as "a private field that is a &T", while the intended reading (I believe) is "given &T, fields of T". But I don't know that this addition is particularly useful. I'd rather add a parenthetical for &mut T:
(with no exception for [
UnsafeCell<U>])
There was a problem hiding this comment.
this could also be read as "a private field that is a &T"
Yes, that is what is meant.
I'd rather add a parenthetical for &mut T:
If we list all the types that are no exception, we'll never be done.
Note that this edit is about your "I thought this was fine because the reference was never visible to the user". That's what I thought you said anyway.
There was a problem hiding this comment.
We can add "no exceptions" without mentioning any particular type. But that's something we could add to every single sentence in the Reference. If people go about randomly assuming exceptions, there's very little we can do.
…eptions to the &mut rule
RalfJung
force-pushed
the
aliasing-in-fields
branch
from
de9c23b to
0b758f2
Compare
3 participants
People might reasonably assume that a reference hidden inside private fields isn't really a reference. Let's make it clear that that's not the case.
This is based on feedback by @jethrogb.