Tracking Issue for `vec_into_chunks`

[ashivaram23]

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)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[scottmcm]

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 that with_capacity(x) means that it has a capacity of exactly x, just that it's https://doc.rust-lang.org/std/alloc/trait.Allocator.html#memory-fitting for x.)

[Scripter17]

Surely it should mirror slice::as_chunks? (Vec<[T; N]>, Vec<T>)

Possibly also a Vec::try_into_chunks for a Result<Vec<[T; N]>, Vec<T>>? Since it's hard to turn my above proposal into that after the chunking.

[scottmcm]

Surely it should mirror slice::as_chunks? (Vec<[T; N]>, Vec<T>)

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-capacity into_chunks would be a big footgun if we ever want to change the growth factor.

[Scripter17]

I wasn't aware it would ever have to reallocate?

A while ago I made a mock up of that by just doing math to the raw parts and Miri seemed fine with it. I might be remembering it wrong but I think making one vector into two disjoint vectors just worked.

If I find it I'll edit it onto this comment.

[scottmcm]

I might be remembering it wrong but I think making one vector into two disjoint vectors just worked.

If either of them has non-zero capacity, it's 100% wrong. When they're dropped they'll have the wrong layout, which is insta-UB, or if you return incorrect capacities to get past that it's a double-free bug that's also insta-UB.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=4aa929cc470057300e8826b46b8c8331

[Scripter17]

Figured out why Miri was happy: I was reallocating.

Sorry for the noise.

[ashivaram23]

Possibly also a Vec::try_into_chunks for a Result<Vec<[T; N]>, Vec>? Since it's hard to turn my above proposal into that after the chunking.

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.

since the current wording for capacity doesn't guarantee that with_capacity(x) means that it has a capacity of exactly x,

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.