Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: Vec { buf: RawVec::with_capacity_in(capacity, alloc), len: 0 } } <del> /// Creates a `Vec<T, A>` directly from the raw components of another vector. </del> <ins> /// Creates a `Vec<T, A>` directly from a pointer, a capacity, a length, /// and an allocator. </ins> /// /// # Safety /// /// This is highly unsafe, due to the number of invariants that aren't /// checked: /// <del> /// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>` ///   (at least, it's highly likely to be incorrect if it wasn't). /// * `T` needs to have the same size and alignment as what `ptr` was allocated with. </del> <ins> /// * `T` needs to have the same alignment as what `ptr` was allocated with. </ins> ///   (`T` having a less strict alignment is not sufficient, the alignment really ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be ///   allocated and deallocated with the same layout.) <ins> /// * The size of `T` times the `capacity` (ie. the allocated size in bytes) needs ///   to be the same size as the pointer was allocated with. (Because similar to ///   alignment, [`dealloc`] must be called with the same layout `size`.) </ins> /// * `length` needs to be less than or equal to `capacity`. <del> /// * `capacity` needs to be the capacity that the pointer was allocated with. </del> <ins> /// * The first `length` values must be properly initialized values of type `T`. /// * `capacity` needs to [*fit*] the layout size that the pointer was allocated with. /// * The allocated size in bytes must be no larger than `isize::MAX`. ///   See the safety documentation of [`pointer::offset`]. /// /// These requirements are always upheld by any `ptr` that has been allocated /// via `Vec<T, A>`. Other allocation sources are allowed if the invariants are /// upheld. </ins> /// /// Violating these may cause problems like corrupting the allocator's /// internal data structures. For example it is **not** safe