Skip to content

Commit

Permalink
be clear that 1-init Vec being valid (but not safe) is not a stable g…
Browse files Browse the repository at this point in the history
…uarantee
  • Loading branch information
RalfJung committed Aug 6, 2019
1 parent e187574 commit 1b9eb4a
Showing 1 changed file with 4 additions and 2 deletions.
6 changes: 4 additions & 2 deletions src/libcore/mem/maybe_uninit.rs
Expand Up @@ -51,7 +51,8 @@ use crate::mem::ManuallyDrop;
///
/// On top of that, remember that most types have additional invariants beyond merely
/// being considered initialized at the type level. For example, a `1`-initialized [`Vec<T>`]
/// is considered initialized because the only requirement the compiler knows about it
/// is considered initialized (under the current implementation, this does not constitute
/// a stable guarantee) because the only requirement the compiler knows about it
/// is that the data pointer must be non-null. Creating such a `Vec<T>` does not cause
/// *immediate* undefined behavior, but will cause undefined behavior with most
/// safe operations (including dropping it).
Expand Down Expand Up @@ -404,7 +405,8 @@ impl<T> MaybeUninit<T> {
///
/// On top of that, remember that most types have additional invariants beyond merely
/// being considered initialized at the type level. For example, a `1`-initialized [`Vec<T>`]
/// is considered initialized because the only requirement the compiler knows about it
/// is considered initialized (under the current implementation, this does not constitute
/// a stable guarantee) because the only requirement the compiler knows about it
/// is that the data pointer must be non-null. Creating such a `Vec<T>` does not cause
/// *immediate* undefined behavior, but will cause undefined behavior with most
/// safe operations (including dropping it).
Expand Down

0 comments on commit 1b9eb4a

Please sign in to comment.