Skip to content

Tracking Issue for cast_maybe_uninit #145036

Open

Description

@clarfonthey

Feature gate: #![feature(cast_maybe_uninit)]

This is a tracking issue for the cast_init and cast_uninit methods on pointers.

Public API

impl<T> *const T {
    pub const fn cast_uninit(self) -> *const MaybeUninit<T>;
}
impl<T> *mut T {
    pub const fn cast_uninit(self) -> *mut MaybeUninit<T>;
}
impl<T> NonNull<T> {
    pub const fn cast_uninit(self) -> NonNull<MaybeUninit<T>>;
}
impl<T> *const MaybeUninit<T> {
    pub const fn cast_init(self) -> *const T;
}
impl<T> *mut MaybeUninit<T> {
    pub const fn cast_init(self) -> *mut T;
}
impl<T> NonNull<MaybeUninit<T>> {
    pub const fn cast_init(self) -> NonNull<T>;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

Unresolved Questions

  • Naming: should cast_init be as_ptr to match MaybeUninit::as_ptr that does the same operation?

Footnotes

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

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 Aug 7, 2025
  2. theemathas commented on Aug 7, 2025

    @theemathas
    Contributor

    Presumably, we'd want a NonNull version of this too? And this should probably work on ?Sized types?

  3. ChrisDenton commented on Aug 7, 2025

    @ChrisDenton
    Member

    Personally I'm not terribly convinced by cast_uninit tbh. It's very common to want to get a "normal" pointer from a &[MaybeUninit<T>] (for ffi or to write through, etc) but a *mut MaybeUninit<T> has no special properties over *mut T. And *const MaybeUninit<T> just seems like a bit of a contradiction in types. After all an &MaybeUninit<T> would be mostly useless, right?

    To be clear, I'm not saying they have no usage whatsoever. Just that it feels quite rare to actually want this.

  4. clarfonthey commented on Aug 7, 2025

    @clarfonthey
    ContributorAuthor

    Presumably, we'd want a NonNull version of this too? And this should probably work on ?Sized types?

    Yes; I forgot that when converting the proposed API into a full list.

  5. clarfonthey commented on Aug 7, 2025

    @clarfonthey
    ContributorAuthor

    Personally I'm not terribly convinced by cast_uninit tbh. It's very common to want to get a "normal" pointer from a &[MaybeUninit<T>] (for ffi or to write through, etc) but a *mut MaybeUninit<T> has no special properties over *mut T. And *const MaybeUninit<T> just seems like a bit of a contradiction in types. After all an &MaybeUninit<T> would be mostly useless, right?

    To be clear, I'm not saying they have no usage whatsoever. Just that it feels quite rare to actually want this.

    @scottmcm's example on the original ACP felt pretty compelling: rust-lang/libs-team#627 (comment)

    Essentially: while APIs operating on MaybeUninit<T> will presumably want easy ways to cast things into ordinary pointers, there will also be APIs which store the ordinary pointers and want to convert them back into MaybeUninit<T>. The example in Vec is just one, but it feels natural that for any API that might want to do one conversion, there will probably be a similar API that would like to do the reverse.

  6. clarfonthey commented on Aug 12, 2025

    @clarfonthey
    ContributorAuthor

    And this should probably work on ?Sized types?

    Actually taking this back: MaybeUninit isn't allowed for unsized types, so, only sized for now.

  7. added a commit that references this issue on Aug 13, 2025
  8. added a commit that references this issue on Aug 13, 2025
  9. added a commit that references this issue on Aug 18, 2025
  10. papill9 commented on Mar 30, 2026

    @papill9

    Is anything blocking this to move to stable?

  11. 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 RFCS-tracking-unimplementedStatus: The feature has not been implemented.T-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