-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add Option::as_
(mut_
)slice
#105871
Add Option::as_
(mut_
)slice
#105871
Conversation
r? @m-ou-se (rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
37b5b52
to
4a52066
Compare
4a52066
to
74b3edc
Compare
Perhaps use the |
I tried that, but it didn't work; the compiler complained that |
99cbfee
to
9c6a7d5
Compare
Given the problem of inference errors, I wonder if we should rename the mutable version of |
9c6a7d5
to
bb671b8
Compare
This comment has been minimized.
This comment has been minimized.
bb671b8
to
f6e39e2
Compare
I had to add |
f6e39e2
to
fbfb3e7
Compare
You could also use |
fbfb3e7
to
daff81a
Compare
Thank you, I had missed that one. |
Option::as_slice
(_mut
) and ::into_slice
Option::as_slice
(_mut
)
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'd really rather not take a linkchecker change here (unless there's a bug it can link to saying this is the best option for now), but other than that it looks good!
This comment has been minimized.
This comment has been minimized.
d47b530
to
9f25458
Compare
@scottmcm I have reverted the linkchecker change and changed the offending links as per your suggestion, let's hope they work this time. |
Thanks! I don't really know the exact intradoc link rules nor the markdown parsing ones, so I'm also just 🤞 |
This adds the following functions: * `Option<T>::as_slice(&self) -> &[T]` * `Option<T>::as_slice_mut(&mut self) -> &[T]` The `as_slice` and `as_slice_mut` functions benefit from an optimization that makes them completely branch-free. Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the `Some(_)` contents zero or the mempory layout of `Option<T>` is equal to that of `Option<MaybeUninit<T>>`.
9f25458
to
41da875
Compare
Ah, glad that one worked! @bors r+ |
Add `Option::as_`(`mut_`)`slice` This adds the following functions: * `Option<T>::as_slice(&self) -> &[T]` * `Option<T>::as_mut_slice(&mut self) -> &[T]` The `as_slice` and `as_mut_slice_mut` functions benefit from an optimization that makes them completely branch-free. ~~Unfortunately, this optimization is not available on by-value Options, therefore the `into_slice` implementations use the plain `match` + `slice::from_ref` approach.~~ Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the `Some(_)` contents zero or the mempory layout of `Option<T>` is equal to that of `Option<MaybeUninit<T>>`. The idea has been discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Option.3A.3Aas_slice). Notably the idea for the `as_slice_mut` and `into_slice´ methods came from `@cuviper` and `@Sp00ph` hardened the optimization against niche-optimized Options. The [rust playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=74f8e4239a19f454c183aaf7b4a969e0) shows that the generated assembly of the optimized method is basically only a copy while the naive method generates code containing a `test dx, dx` on x86_64. --- EDIT from reviewer: ACP is rust-lang/libs-team#150
Add `Option::as_`(`mut_`)`slice` This adds the following functions: * `Option<T>::as_slice(&self) -> &[T]` * `Option<T>::as_mut_slice(&mut self) -> &[T]` The `as_slice` and `as_mut_slice_mut` functions benefit from an optimization that makes them completely branch-free. ~~Unfortunately, this optimization is not available on by-value Options, therefore the `into_slice` implementations use the plain `match` + `slice::from_ref` approach.~~ Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the `Some(_)` contents zero or the mempory layout of `Option<T>` is equal to that of `Option<MaybeUninit<T>>`. The idea has been discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Option.3A.3Aas_slice). Notably the idea for the `as_slice_mut` and `into_slice´ methods came from ``@cuviper`` and ``@Sp00ph`` hardened the optimization against niche-optimized Options. The [rust playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=74f8e4239a19f454c183aaf7b4a969e0) shows that the generated assembly of the optimized method is basically only a copy while the naive method generates code containing a `test dx, dx` on x86_64. --- EDIT from reviewer: ACP is rust-lang/libs-team#150
☀️ Test successful - checks-actions |
Finished benchmarking commit (5423745): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
…trieb Use `Option::as_slice` where applicable After rust-lang#105871 introduced `Option::as_slice`, this PR uses it within the compiler. I found it interesting that all cases where `as_slice` could be used were done with different code before; so it seems the new API also has the benefit of being "the obvious solution" where before there was a mix of options, none clearly better than the rest.
…trieb Use `Option::as_slice` where applicable After rust-lang#105871 introduced `Option::as_slice`, this PR uses it within the compiler. I found it interesting that all cases where `as_slice` could be used were done with different code before; so it seems the new API also has the benefit of being "the obvious solution" where before there was a mix of options, none clearly better than the rest.
This adds the following functions:
Option<T>::as_slice(&self) -> &[T]
Option<T>::as_mut_slice(&mut self) -> &[T]
The
as_slice
andas_mut_slice_mut
functions benefit from an optimization that makes them completely branch-free.Unfortunately, this optimization is not available on by-value Options, therefore theinto_slice
implementations use the plainmatch
+slice::from_ref
approach.Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the
Some(_)
contents zero or the mempory layout ofOption<T>
is equal to that ofOption<MaybeUninit<T>>
.The idea has been discussed on Zulip. Notably the idea for the
as_slice_mut
and `into_slice´ methods came from @cuviper and @Sp00ph hardened the optimization against niche-optimized Options.The rust playground shows that the generated assembly of the optimized method is basically only a copy while the naive method generates code containing a
test dx, dx
on x86_64.EDIT from reviewer: ACP is rust-lang/libs-team#150