Skip to content

Tracking Issue for vec_into_chunks #142137

@ashivaram23

Description

@ashivaram23
Contributor

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.)

  • Final comment period (FCP)1
    Stabilization PR

Unresolved Questions

  • None yet.

Footnotes

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

Activity

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
on Jun 7, 2025
scottmcm

scottmcm commented on Jul 1, 2025

@scottmcm
Member

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

Scripter17 commented on Jul 1, 2025

@Scripter17
Contributor

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.

added a commit that references this issue on Jul 1, 2025
31e6410
scottmcm

scottmcm commented on Jul 1, 2025

@scottmcm
Member

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

Scripter17 commented on Jul 1, 2025

@Scripter17
scottmcm

scottmcm commented on Jul 2, 2025

@scottmcm
Scripter17

Scripter17 commented on Jul 2, 2025

@Scripter17
added a commit that references this issue on Jul 2, 2025
e1c6e93
ashivaram23

ashivaram23 commented on Jul 2, 2025

@ashivaram23
ContributorAuthor

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.

added a commit that references this issue on Jul 2, 2025
686efaa
added 3 commits that reference this issue on Jul 2, 2025
4aedc00
fb8421f
6a31e69
added a commit that references this issue on Jul 2, 2025
added a commit that references this issue on Jul 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-unimplementedStatus: The feature has not been implemented.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @scottmcm@Scripter17@ashivaram23

        Issue actions

          Tracking Issue for `vec_into_chunks` · Issue #142137 · rust-lang/rust