-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Explicitly document the size guarantees that Option makes. #75454
Conversation
Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
library/core/src/option.rs
Outdated
//! Rust guarantees to optimise the following inner types such that an [`Option`] which contains | ||
//! them has the same size as a pointer: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
//! Rust guarantees to optimise the following inner types such that an [`Option`] which contains | |
//! them has the same size as a pointer: | |
//! Rust guarantees to optimize the following types `T` such that an [`Option<T>`] | |
//! has the same size as a `T`: |
Giving names to things helps. :) And we typically use US spelling, AFAIK.
Also maybe say that this means that one may transmute a T
to an Option<T>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Fixed in f5118a5.
library/core/src/option.rs
Outdated
//! * [`num::NonZero*`] | ||
//! * [`ptr::NonNull<T>`] | ||
//! * `#[repr(transparent)]` struct around one of the types in this list. | ||
//! * [`Box<T>`] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In terms of ordering I think it makes more sense to add this to the top or just below the references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Fixed in f5118a5.
Nominating for lang-team discussion. |
library/core/src/option.rs
Outdated
//! * [`Box<T>`] | ||
//! | ||
//! For the above cases, it is guaranteed that one can use [`mem::transmute`] | ||
//! between `T` and `Option<T>` and vice versa. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not vice versa! If you transmute a None
from Option<T>
to T
, you get UB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Should there be a guarantee for non-None
in such a case, or just rule out the reverse direction entirely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guarantee for non-None
seems reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 83f47aa.
Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: Ralf Jung <post@ralfj.de>
@rust-lang/lang another point that is not entirely clear yet is function pointers -- the last FCP only covered |
library/core/src/option.rs
Outdated
//! Rust guarantees to optimize the following types `<T>` such that an | ||
//! [`Option<T>`] has the same size as `T`: | ||
//! | ||
//! * [`Box<T>`] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wording is pretty confusing to me, I think because it uses the same name T
to mean two different things. For example this line is talking about what happens when T = Box<T>
... which is never true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggled to find a good phrasing here; I agree the current phrasing isn't great.
Might something like:
//! Rust guarantees that the following types are optimised such that their size
//! is identical whether or not they are surrounded by an `Option`:
be clearer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just use Box<_>
or Box<U>
. Naming things is generally a good idea, so I'd not remove the T
in the introduction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 68209c3.
Reassigning for reviewing accuracy after discussed by lang team. r? @RalfJung |
library/core/src/option.rs
Outdated
//! in Rust are stored as efficiently as any other pointer type. | ||
//! # Representation | ||
//! | ||
//! Rust guarantees to optimize the following types `<T>` such that an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
//! Rust guarantees to optimize the following types `<T>` such that an | |
//! Rust guarantees to optimize the following types `T` such that an |
I never saw <T>
as notation for a type, not sure what that is supposed to indicate.
Discussed in rust-lang/lang meeting today:
@rfcbot fcp merge |
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
My tuppence worth: if we do add that guarantee (in some form) in, we might want to re-ask those who've signed the CFP off so far? |
@cramertj @pnkfelix @withoutboats there's some FCP checkboxes waiting for you here. :) |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
@bors r+ |
📌 Commit 9bac577 has been approved by |
⌛ Testing commit 9bac577 with merge 1671a2d6368f9890d7db0f6bf5f21226715e0c45... |
…es, r=dtolnay Explicitly document the size guarantees that Option makes. Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer. CC @RalfJung
Rolled up, yielding. |
Rollup of 12 pull requests Successful merges: - rust-lang#75454 (Explicitly document the size guarantees that Option makes.) - rust-lang#76631 (Add `x.py setup`) - rust-lang#77076 (Add missing code examples on slice iter types) - rust-lang#77093 (merge `need_type_info_err(_const)`) - rust-lang#77122 (Add `#![feature(const_fn_floating_point_arithmetic)]`) - rust-lang#77127 (Update mdBook) - rust-lang#77161 (Remove TrustedLen requirement from BuilderMethods::switch) - rust-lang#77166 (update Miri) - rust-lang#77181 (Add doc alias for pointer primitive) - rust-lang#77204 (Remove stray word from `ClosureKind::extends` docs) - rust-lang#77207 (Rename `whence` to `span`) - rust-lang#77211 (Remove unused #[allow(...)] statements from compiler/) Failed merges: - rust-lang#77170 (Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`) r? `@ghost`
Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of
Option<T>
one can guarantee are optimised to a single pointer.CC @RalfJung