-
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
Does [T]::array_chunks
really need to be an iterator?
#76354
Comments
Also related,
It could though, just as |
Let's compare the usage examples with the iterator and the slice. |
|
That's not multiple slices -- a slice of arrays is necessarily just one contiguous allocation. |
The |
The important difference with So that would imply that there'd be both of these
I can go make a PR for the second one of those, if it sounds worthwhile... EDIT: PR #78818 |
Add `as_rchunks` (and friends) to slices `@est31` mentioned (rust-lang#76354 (comment)) that, for completeness, there needed to be an `as_chunks`-like method that chunks from the end (with the remainder at the beginning) like `rchunks` does. So here's a PR for `as_rchunks: &[T] -> (&[T], &[[T; N]])` and `as_rchunks_mut: &mut [T] -> (&mut [T], &mut [[T; N]])`. But as I was doing this and copy-pasting `from_raw_parts` calls, I thought that I should extract that into an unsafe method. It started out a private helper, but it seemed like `as_chunks_unchecked` could be reasonable as a "real" method, so I added docs and made it public. Let me know if you think it doesn't pull its weight.
Add `as_rchunks` (and friends) to slices `@est31` mentioned (rust-lang#76354 (comment)) that, for completeness, there needed to be an `as_chunks`-like method that chunks from the end (with the remainder at the beginning) like `rchunks` does. So here's a PR for `as_rchunks: &[T] -> (&[T], &[[T; N]])` and `as_rchunks_mut: &mut [T] -> (&mut [T], &mut [[T; N]])`. But as I was doing this and copy-pasting `from_raw_parts` calls, I thought that I should extract that into an unsafe method. It started out a private helper, but it seemed like `as_chunks_unchecked` could be reasonable as a "real" method, so I added docs and made it public. Let me know if you think it doesn't pull its weight.
Is this issue resolved now that |
I think it still needs a libs decision for direction here. Could be neither, either, or both. It could be argued that |
Thanks, that makes sense. For what it's worth, I found this issue today because I was looking for a way to safely convert (This use case might become more common when const generics are stabilized, so it would be great to be able to move the array |
Oh, also there's the problem of what to do about @not-an-aardvark If you want to try to push it forward, you could consider making a topic on zulip (https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs) to ask what directions libs would like to go for this -- it might be "actually things seem fine, can you make a stabilization PR with tweaks so that ________________________". |
Thanks, I'll make a topic. I was thinking that |
The unconditional panic can be made conditional by a user's own runtime check, (Just as one might have "runtime" conditions for ZSTs.) |
In cryptographic code we need to be able to split |
That doesn't mean that this behaviour needs to be stuffed into From my perspective, while a method which turns Since the |
I think this already exists as |
Make sure to read previous comments, such as #76354 (comment) and #76354 (comment) |
After bit after reviewing the code in #75021 I had a thought: if this iterator is mostly just a wrapper on a slice iterator, does it even need to be an iterator at all?
The original
.chunks()
call does (as does.windows
), because the slices it wants to return don't exist anywhere.But the arrays returned by
array_chunks
are inline in the original slice allocation, so the API could just return the slice that the method is already creating, instead of hiding it in an iterator.To be more concrete:
Not only would this be more general (the
ArrayChunks
type doesn't currently expose the slice), but I think it would make it less likely that people would forget to correctly handle the.remainder()
. (While still being easy to ignore it with.0
if they insist.) And returning tuples like this has precedent withsplit_*
andalign_to
and such. (Many other names could work too, like.as_chunks(_mut)
.)Also, such a method would be nice to have as the inverse of a hypothetical
flatten: &[[T; N]] -> &[T]
. (EDIT: No longer as hypothetical, #95629.)array_chunks
tracking issue #74985The text was updated successfully, but these errors were encountered: