Add array_windows fn by JulianKnodt · Pull Request #75026 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation15 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This mimicks the functionality added by array_chunks, and implements a const-generic form ofwindows. It makes egregious use of unsafe, but by necessity because the array must be
re-interpreted as a slice of arrays, and unlike array_chunks this cannot be done by casting the
original array once, since each time the index is advanced it needs to move one element, notN.
I'm planning on adding more tests, but this should be good enough as a premise for the functionality.
Notably: should there be more functions overwritten for the iterator implementation/in general?
I've marked the issue as #74985 as there is no corresponding exact issue for array_windows, but it's based of off array_chunks.
Edit: See Issue #75027 created by @lcnr for tracking issue
Do not merge until I add more tests, please.
r? @lcnr
3 tasks
Added a separate tracking issue for array_windows: #75027
Please update the the links for array_windows here
Would it make sense to define next and next_back based on nth and nth_back? They're both just nth(0) and nth_back(0) respectively
Edit: decided to go with defining in terms of this, just reduces the code size and centralizes the logic.
Looks fairly good to me.
It might be more intuitive to only define next and next_back instead and implement nth by self.num.saturating_sub(n); self.next().
I personally don't care either way here.
Not part of T-libs though, so a as final review: @bors r? @withoutboats
This comment has been minimized.
This comment has been minimized.
This seems to be a spurious error, is it possible for tests to be rerun?
Relevant to the library API team, which will review and decide on the PR/issue.
Area: const generics (parameters and arguments)
labels
☔ The latest upstream changes (presumably #76311) 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:
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author
📌 Commit f240abc has been approved by Amanieu
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
16 tasks
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Implement split_array and split_array_mut
This implements [T]::split_array::<const N>() -> (&[T; N], &[T]) and [T; N]::split_array::<const M>() -> (&[T; M], &[T]) and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674.
This implements [T; N]::split_array returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of [T]::split_array could also be added as in rust-lang#76014. This would not be needed for [T; N]::split_array as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Implement split_array and split_array_mut
This implements [T]::split_array::<const N>() -> (&[T; N], &[T]) and [T; N]::split_array::<const M>() -> (&[T; M], &[T]) and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674.
This implements [T; N]::split_array returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of [T]::split_array could also be added as in rust-lang#76014. This would not be needed for [T; N]::split_array as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Implement split_array and split_array_mut
This implements [T]::split_array::<const N>() -> (&[T; N], &[T]) and [T; N]::split_array::<const M>() -> (&[T; M], &[T]) and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674.
This implements [T; N]::split_array returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of [T]::split_array could also be added as in rust-lang#76014. This would not be needed for [T; N]::split_array as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
Labels
Area: const generics (parameters and arguments)
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library API team, which will review and decide on the PR/issue.