Add [T]::as_chunks(_mut) #76635
Add [T]::as_chunks(_mut) #76635
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
scottmcm
force-pushed
the
slice-as-chunks
branch
2 times, most recently
from
dfdb39b
to
f01c932
Compare
|
☔ The latest upstream changes (presumably #76787) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels: |
scottmcm
force-pushed
the
slice-as-chunks
branch
from
f01c932
to
1f84864
Compare
scottmcm
force-pushed
the
slice-as-chunks
branch
from
1f84864
to
203dd9a
Compare
library/core/src/slice/mod.rs
Outdated
| pub fn as_chunks<const N: usize>(&self) -> (&[[T; N]], &[T]) { | ||
| assert_ne!(N, 0); | ||
| let len = self.len() / N; | ||
| let (fst, snd) = self.split_at(len * N); |
There was a problem hiding this comment.
Not a fan of the fst and snd style of abbreviation. I think it's rarely used in this codebase and is generally discouraged. Also, remainder might be a better name for the second part. Applies to the _mut version as well.
There was a problem hiding this comment.
@LukasKalbertodt I asked what is fst and snd in the past and it was encouraged in the pull request, I forgot which pull request was it.
There was a problem hiding this comment.
Okay, interesting. I never saw these specific abbreviations in std's codebase. (Doesn't mean they don't exist, of course)
There was a problem hiding this comment.
Just for reference #75936 (comment) and #75936 (comment), I personally got confused the first time I saw it.
There was a problem hiding this comment.
These names are just moved over from the previous code. I'm not tied to them; new commit to update them incoming.
Allows getting the slices directly, rather than just through an iterator as in `array_chunks(_mut)`. The constructors for those iterators are then written in terms of these methods, so the iterator constructors no longer have any `unsafe` of their own.
scottmcm
force-pushed
the
slice-as-chunks
branch
from
203dd9a
to
652f34d
Compare
|
@LukasKalbertodt Friendly one-week re-review ping. |
|
@bors r+ |
|
📌 Commit 652f34d has been approved by |
bors
added
S-waiting-on-bors
Rollup of 16 pull requests Successful merges: - rust-lang#76635 (Add [T]::as_chunks(_mut)) - rust-lang#77703 (add system-llvm-libunwind config option) - rust-lang#78219 (Prefer to use `print_def_path`) - rust-lang#78298 (Add test for bad NLL higher-ranked subtype) - rust-lang#78332 (Update description for error E0308) - rust-lang#78342 (Use check-pass in single-use-lifetime ui tests) - rust-lang#78347 (Add lexicographical comparison doc) - rust-lang#78348 (Make some functions private that don't have to be public) - rust-lang#78349 (Use its own `TypeckResults` to avoid ICE) - rust-lang#78375 (Use ? in core/std macros) - rust-lang#78377 (Fix typo in debug statement) - rust-lang#78388 (Add some regression tests) - rust-lang#78394 (fix(docs): typo in BufWriter documentation) - rust-lang#78396 (Add compiler support for LLVM's x86_64 ERMSB feature) - rust-lang#78405 (Fix typo in lint description) - rust-lang#78412 (Improve formatting of hash collections docs) Failed merges: r? `@ghost`
| /// ``` | ||
| /// #![feature(slice_as_chunks)] | ||
| /// let slice = ['l', 'o', 'r', 'e', 'm']; | ||
| /// let (chunks, remainder) = slice.as_chunks(); |
There was a problem hiding this comment.
Should the example be: let (...) = slice.as_chunks::<2>();? (Similar for as_chunks_mut.)
I imagine this example with implicit N only works because N is inferred from the subsequent assert_eq! structure. (But I'm pretty new to Rust, so maybe I'm missing something!)
Thanks!
There was a problem hiding this comment.
It does indeed infer N, and that's meant to be a good thing, but perhaps the example should have a comment pointing this out.
There was a problem hiding this comment.
We could either put slice.as_chunks() as comment or slice.as_chunks::<2>() as comment to show that it is being infered.
But in some cases type is not infered which may be confusing, like Some([]) cannot be infered as N for [T; N] so it may contradict to this comment here, so it would also be safer to say "most of the time it could be infered" for now. I recall seeing this in one of the pull request.
There was a problem hiding this comment.
Yes, it does infer N in these cases. I agree it would be nice to also have some examples that turbofish it.
Maybe some like these, to emphasize the length math:
let slice = ['-'; 100];
let (chunks, remainder) = slice.as_chunks::<20>();
assert_eq!((chunks.len(), remainder.len()), (5, 0));
let (chunks, remainder) = slice.as_chunks::<30>();
assert_eq!((chunks.len(), remainder.len()), (3, 10));
Allows getting the slices directly, rather than just through an iterator as in
array_chunks(_mut). The constructors for those iterators are then written in terms of these methods, so the iterator constructors no longer have anyunsafeof their own.Unstable, of course. #74985