Skip to content

Tracking Issue for Vec::split_at_spare_mut #81944

Description

@KodrAus

Feature gate: #![feature(vec_split_at_spare)]

This is a tracking issue for Vec::split_at_spare_mut, which is used as the basis for a few methods internally to give a slice pointing to the initialized portion of the Vec and a slice of MaybeUninit pointing to the uninitialized portion.

Public API

impl<T, A: Allocator> Vec<T, A> {
    pub fn split_at_spare_mut(&mut self) -> (&mut [T], &mut [MaybeUninit<T>]) {}
}

Steps / History

Unresolved Questions

  • Should we consider changing the name? split_at_spare_mut doesn't seem like an intuitive name
  • Should we deprecate Vec::spare_capacity_mut? Any usecase of Vec::spare_capacity_mut can be replaced with Vec::split_at_spare_mut (but not vise-versa):
    edit: spare_capacity_mut has been stabilised now in Stabilize vec_spare_capacity #93016 so deprecating it is probably not an option

Activity

  1. added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Feb 9, 2021
  2. Amanieu commented on Feb 10, 2021

    @Amanieu
    Member

    Interesting! I personally use spare_capacity_mut in my code to read into uninitialized buffers. I feel that it may be worth keeping it as a convenience method, but then again it is quite rarely used so I don't mind having to write an extra .1.

  3. WaffleLapkin commented on Feb 10, 2021

    @WaffleLapkin
    Member

    Hm, why there are no unresolved questions yet? It doesn't seem that the questions from the implementation PR were resolved:

    • Should we consider changing the name? split_at_spare_mut doesn't seem like an intuitive name
    • Should we deprecate Vec::spare_capacity_mut? Any usecase of Vec::spare_capacity_mut can be replaced with Vec::split_at_spare_mut (but not vise-versa)
  4. KodrAus commented on Feb 21, 2021

    @KodrAus
    ContributorAuthor

    @WaffleLapkin I just missed those questions that came up after the PR approval is all 🙂 They're in the tracking issue now.

  5. RalfJung commented on Feb 21, 2021

    @RalfJung
    Member

    Any usecase of Vec::spare_capacity_mut can be replaced with Vec::split_at_spare_mut (but not vise-versa)

    That is not true: split_at_spare_mut creates mutable references to the entire initialized part of the vector and will thus invalidate any preexisting pointers. spare_capacity_mut, if it is implemented carefully (which I have not checked) could be made to not invalidate existing pointers into the initialized part of the vector.

  6. WaffleLapkin commented on Feb 21, 2021

    @WaffleLapkin
    Member

    @RalfJung ohhh. I haven't thought of this. Then I guess the question "do we need both?" is resolved: yes.

    if it is implemented carefully

    Current implementation just calls self.split_at_spare_mut().1 😅

  7. RalfJung commented on Feb 21, 2021

    @RalfJung
    Member

    Current implementation just calls self.split_at_spare_mut().1

    Well, that doesn't count as "careful" I guess. ;)

  8. WaffleLapkin commented on Feb 21, 2021

    @WaffleLapkin
    Member

    I guess so 😅

    I'll try to make the implementation more careful (revert it?) and make a PR :)

  9. added a commit that references this issue on Mar 4, 2021
  10. added 2 commits that reference this issue on Mar 4, 2021
  11. saethlin commented on Jan 4, 2022

    @saethlin
    Member

    Oops, what I commented here is far more relevant to Vec::spare_capacity_mut, comment moved: #75017 (comment)

  12. ast-ral commented on Apr 23, 2026

    @ast-ral
    Contributor

    Apologies if this is out of place, but it might be good to have a analogous leak_and_split_spare_capacity_mut method, since leak doesn't shrink the vector before returning and there's no (safe) way to get access to the unused capacity that I'm aware of.

  13. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
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 RFCT-libsRelevant to the library 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

      Issue actions