-
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
Add core::slice::Split::as_slice #92287
Conversation
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
52f228d
to
9dd2fe0
Compare
9dd2fe0
to
4fa8076
Compare
This comment has been minimized.
This comment has been minimized.
4fa8076
to
ab7b67f
Compare
This comment has been minimized.
This comment has been minimized.
ab7b67f
to
3eb7931
Compare
triage: What's the status of this PR? |
triage: |
r? @yaahc |
@rustbot author |
3eb7931
to
7d9a278
Compare
This comment has been minimized.
This comment has been minimized.
03c0d31
to
26fd042
Compare
This adds a remainder function to the Slice iterator, so that a caller can access unused elements if iteration stops.
26fd042
to
494901c
Compare
Awesome, looks great. Thank you @JulianKnodt ^_^ @bors r+ |
📌 Commit 494901c has been approved by |
Is there actually any reason to return empty slice if there is no elements left? Because in that case in next step we need to check is that slice empty on not. Why not instead: pub fn as_slice(&self) -> Option<&'a [T]> {
if self.finished { None } else { Some(&self.v) }
} P.S. currently function named as |
@klensy If you convert it to From a reader's point of view, I'm not sure it's semantically more clear to return an optional slice. From seeing it, I'd be surprised that it returned an optional slice, and not be sure when it would return |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d5ae66c): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
Visiting for weekly performance triage. The perf run says this regressed externs (a secondary benchmark) incr-full in debug and opt profiles by 1.2% From my reading of a local cachegrind run on the benchmark, the entirety of the regression is from a closure within I suspect that may be consistent with overhead you get from slight changes in where definitions end up in the encoded metadata from a change like this to libstd. But also, if you look at the graph, it looks like this is variance that immediately resolved itself in the history of that benchmark: @rustbot label: +perf-regression-triaged |
This adds a remainder function to the Slice iterator, so that a caller can access unused
elements if iteration stops.
Addresses #91733