????? add slice::array_chunks by lcnr · Pull Request #72334 · 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
Conversation9 Commits4 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 }})
adds a currently somewhat unuseable implementation of #60735.
cc @DutchGhost
I am not sure if this does more harm than good by showing it in the stable docs, but this felt like a nice challenge of my knowledge of the current state of const generics.
r? @varkor for the const generics bit
edit: the biggest problem is #71154, which prevents all uses of slice.arraychunks::<{expr}>() and some type inference stuff which may already be fixed on the currently nightly
Oh! array_chunks, I like that name!
I remember the compiler got a little wonky when array_chunks was a method on [T].
I also remember it was a little less wonky when using a freestanding function as I wrote in #60735 (comment).
Perhaps it's something to investigate if we want this feature to (finally) be usable in nightly?
However I found the free standing function a bit of a downside if it goes for how the resulting code looks at userlevel. <[...]>::array_chunks(slice) vs slice.array_chunks().
To be fair, the compiler is always a little wonky atm 😆
Free standing functions work as const_chunks_exact::<_, 3> is not a type dependent path,
i.e. we already know which method is used here during ast lowering.
For v.array_chunks, we must know the type of v to get the method definition of array_chunks, and therefore the expected type of 3. This would currently cause a cycle error if we tried to look it up. I tried to explain this problem in more detail in the description of #71154.
<[...]>::array_chunks(slice) also works for methods taking self
Can we make it a method, but enforce function style calling for now? Mainly I find it concerning that when called as method, rustc ICE's. I don't think its good for libcore to have code that crashes rustc when called 'wrong'
Panics if
Nis 0.
Wish this to happen at compile-time.
Can we make it a method, but enforce function style calling for now?
Sadly not, as slice.array_chunks::<{expr}>() cases an ice even in cases where slice.array_chunks is invalid (e.g. array chunks is not a method of slice).
So even if we change array_chunks to take slice: &Self instead, we still get the same ICE and also can't use let [a, b] = slice.array_chunks().next().unwrap(); anymore.
I'm going to mark this as a draft for now, because I don't think we're ready to add this even unstably yet, when it's too prone to ICEing. Hopefully we'll be able to get the remaining issues ironed out before too long.
@rustbot modify labels to S-waiting-on-author -S-waiting-on-review
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
I'm going to close this. Leaving it open will just accumulate conflicts and things may change in the future. Better to create a new PR when revisiting it.
Status: Inactive and waiting on the author. This is often applied to closed PRs.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
add slice::array_chunks to std
Now that rust-lang#74113 has landed, these methods are suddenly usable. A rebirth of rust-lang#72334
Tests are directly copied from chunks_exact and some additional tests for type inference.
r? @withoutboats as you are both part of t-libs and working on const generics. closes rust-lang#60735
Labels
Status: Inactive and waiting on the author. This is often applied to closed PRs.