Skip to content

Commit 1b9eb4a

Browse files
committed
be clear that 1-init Vec being valid (but not safe) is not a stable guarantee
1 parent e187574 commit 1b9eb4a

File tree

1 file changed

+4
-2
lines changed

1 file changed

+4
-2
lines changed

src/libcore/mem/maybe_uninit.rs

+4-2
Original file line numberDiff line numberDiff line change
@@ -51,7 +51,8 @@ use crate::mem::ManuallyDrop;
5151
///
5252
/// On top of that, remember that most types have additional invariants beyond merely
5353
/// being considered initialized at the type level. For example, a `1`-initialized [`Vec<T>`]
54-
/// is considered initialized because the only requirement the compiler knows about it
54+
/// is considered initialized (under the current implementation, this does not constitute
55+
/// a stable guarantee) because the only requirement the compiler knows about it
5556
/// is that the data pointer must be non-null. Creating such a `Vec<T>` does not cause
5657
/// *immediate* undefined behavior, but will cause undefined behavior with most
5758
/// safe operations (including dropping it).
@@ -404,7 +405,8 @@ impl<T> MaybeUninit<T> {
404405
///
405406
/// On top of that, remember that most types have additional invariants beyond merely
406407
/// being considered initialized at the type level. For example, a `1`-initialized [`Vec<T>`]
407-
/// is considered initialized because the only requirement the compiler knows about it
408+
/// is considered initialized (under the current implementation, this does not constitute
409+
/// a stable guarantee) because the only requirement the compiler knows about it
408410
/// is that the data pointer must be non-null. Creating such a `Vec<T>` does not cause
409411
/// *immediate* undefined behavior, but will cause undefined behavior with most
410412
/// safe operations (including dropping it).

0 commit comments

Comments
 (0)