You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
theemathas commentedon Aug 7, 2025
Presumably, we'd want a
NonNullversion of this too? And this should probably work on?Sizedtypes?ChrisDenton commentedon Aug 7, 2025
Personally I'm not terribly convinced by
cast_uninittbh. 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 commentedon Aug 7, 2025
Yes; I forgot that when converting the proposed API into a full list.
clarfonthey commentedon Aug 7, 2025
@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 intoMaybeUninit<T>. The example inVecis 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 commentedon Aug 12, 2025
Actually taking this back:
MaybeUninitisn't allowed for unsized types, so, only sized for now.Rollup merge of rust-lang#145325 - clarfonthey:cast-init, r=scottmcm
Unrolled build for #145325
Rollup merge of rust-lang#145325 - clarfonthey:cast-init, r=scottmcm
papill9 commentedon Mar 30, 2026
Is anything blocking this to move to stable?