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
Should we rename into_inner? Should it be more like take instead and take &mut self?
Should MaybeUninit<T> be Copy for T: Copy?
Should we allow calling get_ref and get_mut (but not reading from the returned references) before data got initialized? (AKA: "Are references to uninitialized data insta-UB, or only UB when being read from?") Should we rename it similar to into_inner?
Can we make into_inner (or whatever it ends up being called) panic when T is uninhabited, like mem::uninitialized does currently? (done)
Seems like we want to not deprecate mem::zeroed. We should however remember to also update its documentation together with MaybeUninit, make sure people are aware that this is insta-UB if all-0-bits does not satisfy the type's validity invariant.
NEW TRACKING ISSUE = #63566
This is a tracking issue for the RFC "Deprecate
uninitializedin favor of a newMaybeUninittype" (rust-lang/rfcs#1892).Steps:
Unresolved questions:
Should we have a safe setter that returns an&mut T?Should we renameMaybeUninit? (RenameMaybeUninittoMaybeUninitialized#56138)Should we renameinto_inner? Should it be more liketakeinstead and take&mut self?ShouldMaybeUninit<T>beCopyforT: Copy?get_refandget_mut(but not reading from the returned references) before data got initialized? (AKA: "Are references to uninitialized data insta-UB, or only UB when being read from?") Should we rename it similar tointo_inner?Can we make(done)into_inner(or whatever it ends up being called) panic whenTis uninhabited, likemem::uninitializeddoes currently?Seems like we want to not deprecatemem::zeroed. We should however remember to also update its documentation together withMaybeUninit, make sure people are aware that this is insta-UB if all-0-bits does not satisfy the type's validity invariant.