-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Renamed infos for clarity, consistency, and succinctness #597
base: pfb/extra-info
Are you sure you want to change the base?
Conversation
…formation from the graphs
Co-authored-by: Khyber Sen <[email protected]>
Co-authored-by: Khyber Sen <[email protected]>
Co-authored-by: Khyber Sen <[email protected]>
Co-authored-by: Khyber Sen <[email protected]>
3b5d06c
to
f547ea3
Compare
|
Isn't aliases the opposite of unique? I much prefer |
You can have references that alias (in that they point to the same memory location) but are still unique / let x: &mut i32 = ...;
let y = &mut *x;
f(y);
f(x);
|
If they alias, then they are not unique, by the common definitions of those words. I think in the Rust sense, it's understood that you can't actively use mutably aliased references or pointers in that the uniqueness or aliasing property is determined at use time. Unique and alias are pretty antonyms to me, so I don't think there's any incompatibility between them. The issue you highlighted above is just as much a problem for calling things unique. And alias is quite common terminology used in Rust, so I think it makes a lot of sense to use as an antonym to unique, in the aliased xor mutable (unique) sense. |
655d0b4
to
38f5f06
Compare
Renamed infos for clarity, consistency, and succinctness. Specifically,
mut
renamed tostore
to matchload
non_unique
renamed toalias
, as this more closely follows Rust's terminology for aliasing, and is also more succinct