Closed
Description
NEW TRACKING ISSUE = #63566
This is a tracking issue for the RFC "Deprecate uninitialized
in favor of a new MaybeUninit
type" (rust-lang/rfcs#1892).
Steps:
- Implement the RFC (cc @rust-lang/libs)
- Adjust documentation (in stabilize core parts of MaybeUninit #60445)
- Stabilization PR (in stabilize core parts of MaybeUninit #60445)
Unresolved questions:
Should we have a safe setter that returns an&mut T
?Should we renameMaybeUninit
? (RenameMaybeUninit
toMaybeUninitialized
#56138)Should we renameinto_inner
? Should it be more liketake
instead and take&mut self
?ShouldMaybeUninit<T>
beCopy
forT: Copy
?- Should we allow calling
get_ref
andget_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 whenT
is uninhabited, likemem::uninitialized
does 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.
Metadata
Metadata
Assignees
Labels
Blocker: Approved by a merged RFC but not yet implemented.Category: An issue tracking the progress of sth. like the implementation of an RFCCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Relevant to the language team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.