Explicitly document the size guarantees that Option makes.#75454
Explicitly document the size guarantees that Option makes.#75454bors merged 8 commits intorust-lang:masterfrom ltratt:option_optimisation_guarantees
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.
| //! 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>?
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.
In terms of ordering I think it makes more sense to add this to the top or just below the references.
|
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.
No, not vice versa! If you transmute a None from Option<T> to T, you get UB.
There was a problem hiding this comment.
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.
Guarantee for non-None seems reasonable.
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.
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.
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.
Maybe just use Box<_> or Box<U>. Naming things is generally a good idea, so I'd not remove the T in the introduction.
|
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.
| //! 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