Tracking Issue for `cast_maybe_uninit`

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

• ACP: ACP: cast_init method for pointers libs-team#627
• Implementation: Add cast_init and cast_uninit methods for pointers #145325
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[theemathas]

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

[ChrisDenton]

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.

[clarfonthey]

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.

[clarfonthey]

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.

[clarfonthey]

And this should probably work on ?Sized types?

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

[appleGun22]

Is anything blocking this to move to stable?