(i can explain more if y'all need, but most of the context is in the git issue and twitter thread)
The necessary layout guarantee was discussed as part of RFC 2645, though not so much in the context of heap allocation. That RFC doesn't actually make
MaybeUninit<T> be laid out as
T but the desire to do so was part of the motivation, and the discussion of this point was largely about whether extending repr(transparent) is the best way to provide that guarantee or whether we should guarantee it in other ways. Nobody questioned that it's a good thing IIRC.
However, the discussion there also highlighted a caveat: when layout optimizations are involved, it's sometimes impossible to treat
A<MaybeUninit<T>> the same as
A<T> (e.g., for
MaybeUninit<T> has no niches even if
T has them. IOW, "transparent wrapper" only means same size and alignment, not same niches. That isn't a problem for any of the standard collections as far as I recall, but it means such transmuting needs to be explicitly blessed by each individual collection, it can't be a blanket property of MaybeUninit.
Associated types and constants already mean
A<TransparentNewtypeOfT> may not have the same layout, but when this occurs it's generally more obvious from the definition of the type and the bounds placed on the type parameter.
(answering on GH to avoid having two threads)