Repository navigation
Tracking Issue for option_as_slice #108545
Description
Feature gate: #![feature(option_as_slice)]
This is a tracking issue for the Option::as_slice and Option::as_mut_slice methods.
The functions return an immutable or mutable slice to the value contained in the Option, if any. Otherwise an empty slice is returned.
Public API
// core::option
impl Option {
pub fn as_slice(&self) -> &[T] { .. }
pub fn as_mut_slice(&mut self) -> &mut [T] { .. }
}Steps / History
- Implementation:
- Final comment period (FCP)1
- Stabilization PR stabilize
Option::as_(mut_)slice#116220
Unresolved Questions
The current implementation contains an optimization which relies on the fact that layout randomization as currently implemented only applies to individual variants, never to the discriminant, and thus the offset of the value within Some(value) is always either 0 (because of niche optimization) or would be the same if the type was Option<MaybeUninit<T>> instead of Option<T>.
Before stabilization, the implementation should be changed to either use an intrinsic to get the offset or extend the offset_of! macro (recently merged RFC#3308) to cover enum variants and use that. There might also be a smaller solution (that we'd still need to check re the rules of Rust layout), which would simply be mem::size_of::<Option<T>>() - mem::size_of::<T>(). I can see that this works for all types I've tested it with, and indeed I'm quite sure that it will work perfectly with the current layout implementation, but I'd like someone from the types team have a look at it before actually using it in a stable API.
The implementation now uses an approach that's always sound (just less efficient than optimal if the hack guesses wrong). A stabilization conversation would probably still want to discuss whether we're comfortable with shipping that approach as stable (since the implementation could be improved non-breakingly later) or we'd prefer to wait for a more principled approach (such as an extension of offset_of! from rust-lang/rfcs#3308 that allows enum variants) first.
Activity
Auto merge of rust-lang#108623 - scottmcm:try-different-as-slice-impl…
scottmcm commentedon Mar 13, 2023
Updated the discussion in the OP now that the implementation relies on the layout estimate only for performance, not for soundness.
llogiq commentedon Mar 13, 2023
I'll push another version using an intrinsic shortly, so we'll have performance and soundness.
Edit: #109095
llogiq commentedon Mar 19, 2023
Superceded by #109179 with a more direct approach using an intrinsic instead of a hacky estimate.
llogiq commentedon Sep 17, 2023
Stabilization Report
Implementation History
Option::as_(mut_)slice#105871Option::as_sliceto an always-sound implementation #108623 fixed a potential soundness issueoffset_of!once that is available for enumsAPI summary
The API is summarized at the top of this tracking issue.
Experience Report
Shortly after the initial implementation, #108678 dogfooded the feature in the compiler, adding 8 lines and removing 17. All four of the cases were both perf and legibility wins. The author notes that there he found some other cases outside of rustc where the feature could be applied, though isn't yet because of not being stabilized, even though his search was merely for a naive implementation of the feature, there may be cases where people have resorted to using a
Vecor other type instead of anOptionto getas_slice. Those cases aren't as easy to find though.Stabilizing this feature will bring the standard library up to parity with the author's optional crate (though that is only for bools, ints and floats).
The API as it is now mirrors that of other collections (notably array,
Vec,BinaryHeapandVecDequeas well as various of their iterators. The only possible extension that was hinted at during development was toDerefOptioninto a possibly empty slice, but this wasn't attempted due to being a breaking change.Finally, I want to note that we can still change the implementation once
offset_of!on enums is available, as the API surface will stay the same. So this seems like as good a time as any to stabilize this feature. Shall we?ping @rust-lang/libs-api
BurntSushi commentedon Sep 17, 2023
@rfcbot merge
rfcbot commentedon Sep 17, 2023
Team member @BurntSushi 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.
rfcbot commentedon Sep 17, 2023
🔔 This is now entering its final comment period, as per the review above. 🔔
AnthonyMikh commentedon Sep 26, 2023
Is it a hard requirement for an empty slice to point to the same place as if
OptionwasSome? Because the pointer part of slice just need to be non-null and sufficiently aligned, so using the address of anOptionitself (as well asNonNull::dangling().as_ptr()) is always the sound approach.scottmcm commentedon Sep 27, 2023
Well, the API doesn't guarantee it in the docs, so I don't think it's a hard requirement.
It's an important QoI detail for performance, though. By returning the empty slice pointing at where the item would be, it's always returning the same pointer. That simplifies codegen and optimizations, by not needing the extra conditional instruction.
Compare these: https://rust.godbolt.org/z/reqcM84xz
llogiq commentedon Sep 27, 2023
As there were no concerns brought up so far, I'll likely push a stabilization PR later today.
rfcbot commentedon Sep 27, 2023
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.
This will be merged soon.
Rollup merge of rust-lang#116220 - llogiq:stabilize-option-as-slice, …
Rollup merge of rust-lang#116220 - llogiq:stabilize-option-as-slice, …
Unrolled build for rust-lang#116220
ChayimFriedman2 commentedon Feb 28, 2024
This should be closed as the feature was stabilized.