Repository navigation
Tracking Issue for vec_into_chunks #142137
Description
Feature gate: #![feature(vec_into_chunks)]
This is a tracking issue for Vec::into_chunks. The ACP is in rust-lang/libs-team#583.
This converts Vec<T> into Vec<[T; N]>, reversing Vec::into_flattened.
Public API
// alloc::vec
impl<T, A: Allocator> Vec<T, A> {
pub fn into_chunks<const N: usize>(mut self) -> Vec<[T; N], A>;
}Steps / History
(Remember to update the S-tracking-* label when checking boxes.)
- Implementation: Add
Vec::into_chunks#142138 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Activity
scottmcm commentedon Jul 1, 2025
I think the big semantic question here is what should happen for non-multiple lengths and capacities. The ACP had it silently remove a tail and reallocate if needed. I could also imagine stricter versions that returned
Results or something at least if the length isn't a multiple. (Capacity is complicated, I guess, since the current wording for capacity doesn't guarantee thatwith_capacity(x)means that it has a capacity of exactlyx, just that it's https://doc.rust-lang.org/std/alloc/trait.Allocator.html#memory-fitting forx.)Scripter17 commentedon Jul 1, 2025
Surely it should mirror slice::as_chunks?
(Vec<[T; N]>, Vec<T>)Possibly also a
Vec::try_into_chunksfor aResult<Vec<[T; N]>, Vec<T>>? Since it's hard to turn my above proposal into that after the chunking.Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
scottmcm commentedon Jul 1, 2025
That's fine if there happens to be no remainder, but comes at the cost of making a separate allocation for the tail if there is one. I guess -- if we had the type in core and could write its type -- it could be
(Vec<[T; N]>, ArrayVec<T, {N - 1}>)though?That still doesn't solve the capacity question, though, as it might still have to reallocate for that. Maybe that's fundamental, though, due to the minimal guarantees we offer about capacity anyway.
pushing a bunch of times then calling a fallible-on-capacityinto_chunkswould be a big footgun if we ever want to change the growth factor.Scripter17 commentedon Jul 1, 2025
scottmcm commentedon Jul 2, 2025
Scripter17 commentedon Jul 2, 2025
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
ashivaram23 commentedon Jul 2, 2025
I think this is nice, it would make the method pretty lightweight in terms of allocator action since you're no longer possibly dropping a bunch of elements or deallocating upon failure, only reallocating for capacity.
Hmm so it would be technically possible to do nothing when the capacity is larger? I guess it can't work with the way capacity is tracked as a number of elements though.
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…
Unrolled build for #142138
Rollup merge of rust-lang#142138 - ashivaram23:vec_into_chunks, r=sco…