be clear that 1-init Vec being valid (but not safe) is not a stable guarantee

1 files changed, 4 insertions, 2 deletions

diff --git a/src/libcore/mem/maybe_uninit.rs b/src/libcore/mem/maybe_uninit.rs
index 20367f724b6..43c4b491ac8 100644
--- a/src/libcore/mem/maybe_uninit.rs
+++ b/src/libcore/mem/maybe_uninit.rs
@@ -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).
@@ -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).