Stream: t-lang/wg-unsafe-code-guidelines

Topic: `MaybeUninit` on the heap


Manish Goregaokar (May 21 2019 at 15:56, on Zulip):

https://github.com/rust-lang/rust/issues/61011

Manish Goregaokar (May 21 2019 at 15:57, on Zulip):

https://twitter.com/ManishEarth/status/1130855712869867522

Manish Goregaokar (May 21 2019 at 15:57, on Zulip):

(i can explain more if y'all need, but most of the context is in the git issue and twitter thread)

rkruppe (May 21 2019 at 16:37, on Zulip):

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 A = Option) because 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<T> and 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.

RalfJ (May 21 2019 at 17:31, on Zulip):

(answering on GH to avoid having two threads)

Last update: Nov 19 2019 at 17:40UTC