Tracking Issue for pointer metadata APIs

[KodrAus]

This is a tracking issue for the RFC 2580 "Pointer metadata & VTable" (rust-lang/rfcs#2580).
The feature gate for the issue is #![feature(ptr_metadata)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (cc @rust-lang/libs @rust-lang/lang -- can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Language-level:

• Is it, or should it be UB (through validity or safety invariants) to have a raw trait object wide pointer with an dangling vtable pointer? A null vtable pointer? If not, DynMetadata methods like size may need to be unsafe fn. Or maybe something like *const () should be metadata of trait objects instead of DynMetadata.
  Right now, there is some inconsistency here: size_of_val_raw(ptr) is unsafe, but metadta(ptr).size_of() does the same thing and is safe.
  Update (2024-10-04): It is definitely the case that the safety invariant for raw trait objects requires a valid vtable. So metadta(ptr).size_of() being safe is fine. size_of_val_raw(ptr) must be unsafe because of slices, so there is no inconsistency here.
• should Metadata be required to be Freeze

API level:

• Is *const () appropriate for the data component of pointers? Or should it be *const u8? Or *const Opaque with some new Opaque type? (Respectively *mut () and NonNull<()>)
• Should ptr::from_raw_parts and friends be unsafe fn?
• Should Thin be added as a supertrait of Sized? Or could it ever make sense to have fat pointers to statically-sized types?
• Should DynMetadata not have a type parameter? This might reduce monomorphization cost, but would force that the size, alignment, and destruction pointers be in the same location (offset) for every vtable. But keeping them in the same location is probaly desirable anyway to keep code size small.
• ACP: replace use of Pointee trait with a ptr::Metadata type libs-team#246
• DynMetadata::size_of does not always return the same value as size_of_val since the former only reads the size from the vtable, but the latter computes the size of the entire type. That seems like a pretty bad footgun?

API bikesheds:

• Name of new items: Pointee (v.s. Referent?), Thin (ThinPointee?), DynMetadata (VTablePtr?), etc
• Location of new items in core::ptr. For example: should Thin be in core::marker instead?

Implementation history

• Implement RFC 2580: Pointer metadata & VTable #81172 Initial implementation

Tracked APIs

Last updated for #81172.

pub trait Pointee {
    /// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>`
    type Metadata;
}

pub trait Thin = Pointee<Metadata = ()>;

pub const fn metadata<T: ?Sized>(ptr: *const T) -> <T as Pointee>::Metadata {}

pub const fn from_raw_parts<T: ?Sized>(*const (), <T as Pointee>::Metadata) -> *const T {}
pub const fn from_raw_parts_mut<T: ?Sized>(*mut (), <T as Pointee>::Metadata) -> *mut T {}

impl<T: ?Sized> NonNull<T> {
    pub const fn from_raw_parts(NonNull<()>, <T as Pointee>::Metadata) -> NonNull<T> {}

    /// Convenience for `(ptr.cast(), metadata(ptr))`
    pub const fn to_raw_parts(self) -> (NonNull<()>, <T as Pointee>::Metadata) {}
}

impl<T: ?Sized> *const T {
    pub const fn to_raw_parts(self) -> (*const (), <T as Pointee>::Metadata) {}
}

impl<T: ?Sized> *mut T {
    pub const fn to_raw_parts(self) -> (*mut (), <T as Pointee>::Metadata) {}
}

/// `<dyn SomeTrait as Pointee>::Metadata == DynMetadata<dyn SomeTrait>`
pub struct DynMetadata<Dyn: ?Sized> {
    // Private pointer to vtable
}

impl<Dyn: ?Sized> DynMetadata<Dyn> {
    pub fn size_of(self) -> usize {}
    pub fn align_of(self) -> usize {}
    pub fn layout(self) -> crate::alloc::Layout {}
}

unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {}
unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {}

[matthieu-m]

After experimenting with custom implementations of Box, I think there is a strong case for having strongly typed meta-data for all kinds of pointers.

The pre-allocator representation of Box is:

struct Box<T: ?Sized> { ptr: NonNull<T>, }

The post-allocator representation is very similar:

struct Box<T: ?Sized, A: Allocator = Global> {
    allocator: A,
    ptr: NonNull<T>,
}

Both automatically implements CoerceUnsized<Box<U>> where T: Unsize<U>, and all is well.

If one wants to make Box generic over its storage, then the representation becomes:

pub struct RawBox<T: ?Sized + Pointee, S: SingleElementStorage> {
    storage: S,
    handle: S::Handle<T>,
}

If S::Handle<T> == NonNull<T>, then Box is still coercible; however, in the case of inline storage, that is:

• neither possible: when the Box is moved, so is the storage, and therefore any pointer into the storage is invalidated.
• nor desirable: in the case of inline storage, the pointer is redundant, wasting 8 bytes.

Hence, in the case of inline storage, S::Handle<T> is best defined as <T as Pointee>::Metadata.

In order to have Box<T> : CoerceUnsized<Box<U>> where T: Unsize<U>:

• We need: S::Handle<T>: CoerceUnsized<S::Handle<U>> where T: Unsize<U>,
• Which means: <T as Pointee>::Metadata: CoerceUnsized<<U as Pointee>::Metadata>> where T: Unsize<U>.

And of course, Box being coercible is very much desirable.

---

As a result, I believe a slight change of course is necessary:

1. All metadata should be strongly typed -- be it Metadata<dyn Debug>, Metadata<[u8]> or Metadata<[u8; 3]> -- no more () or usize.
2. The compiler should automatically implement Metadata<T>: CoerceUnsized<Metadata<U>> where T: Unsize<U>.

I would note that having a single Metadata<T> type rather than SizedMetadata<T>, SliceMetadata<[T]>, DynMetadata<dyn T> is not necessary, only the coercion is, and since the compiler is generating those, it's perfectly free to create them "cross type". I just used the same name as a short-cut.

---

Addendum: What's all that jazz about inline storage?

At a high-level, Box is not so much about where memory comes from, it's a container which allows:

• Dynamically Sized Types.
• And therefore Type Erasure.

Having the memory inline in the Box type preserves those 2 key properties whilst offering a self-contained type (not tied to any lifetime, nor any thread). It's allocation-less type-erasure.

A motivating example is therefore fn foo<T>() -> Box<dyn Future<T>, SomeInlineStorage>: it returns a stack-allocated container which contains any future type (fitting in the storage) which can evaluate to T.

[SimonSapin]

Box<dyn Future<T>, SomeInlineStorage> would have to be dynamically-sized itself, right? So in order to manipulate it without another lifetime or heap-allocated indirection you’d need the unsized locals language feature. And if you have that you can manipulate dyn Future<T> directly, so what’s the point of a box with inline storage?

IMO this is different from the case of Vec, which provides useful functionality on top of its storage so that ArrayVec (a.k.a. Vec with inline storage) makes sens. But Box pretty much is its storage.

[matthieu-m]

Box<dyn Future<T>, SomeInlineStorage> would have to be dynamically-sized itself, right?

No, that's the whole point of it actually.

In C++, you have std::string and std::function implementation typically using the "short string optimization", that is a sufficiently small payload is just embedded inside, and larger ones require a heap-allocation.

This is exactly the same principle:

• libstdc++'s std::string can contain up to 15 non-NUL characters without heap allocation on 64-bits platform.
• sizeof(std::string) == 24, regardless of whether it's empty, contains a single character, or contains 15.

So, here, SomeInlineStorage is generally speak over-reserving. You settle on a fixed alignment and size, and then you may get mem::size_of::<Box<dyn Future, SomeInlineStorage>>() == 128 regardless of what's stored inside.

If you stored a single pointer (+v-table), well, you're paying a bit too much, but that's the price for flexibility. It's up to you size it appropriately for the largest variant.

In any case, unsized locals is strictly unnecessary, as can be seen in the tests of storage-poc's RawBox.

[SimonSapin]

Oh I see, so this is more like SmallVec than ArrayVec and "inline" really means inline up to a certain size chosen a compile-time, and heap-allocated for values that turn out at run-time to be larger?

Back to pointer metadata though, I have a bit of a hard time following the CoerceUnsized discussion. But could you manage what you want if the handle for storage-generic Box<T> is not T::Metadata directly but another generic struct that contains that together with PhandomData<T>?

[matthieu-m]

Oh I see, so this is more like SmallVec than ArrayVec and "inline" really means inline up to a certain size chosen a compile-time, and heap-allocated for values that turn out at run-time to be larger?

It's up to you, you can have either a purely inline storage, or you can have "small" inline storage with heap fallback.

The main point is that the "inline" portion is always of fixed size and alignment (up to the storage) and therefore RawBox itself is always Sized.

(You can an equivalent of ArrayVec instantiated in this test-suite: RawVec<T, inline::SingleRange<...>>)

Back to pointer metadata though, I have a bit of a hard time following the CoerceUnsized discussion. But could you manage what you want if the handle for storage-generic Box<T> is not T::Metadata directly but another generic struct that contains that together with PhandomData<T>?

I don't think so, given the language from the documentation of CoerceUnsized:

For custom types, the coercion here works by coercing Foo<T> to Foo<U> provided an impl of CoerceUnsized<Foo<U>> for Foo<T> exists.

Such an impl can only be written if Foo<T> has only a single non-phantomdata field involving T.

If the type of that field is Bar<T>, an implementation of CoerceUnsized<Bar<U>> for Bar<T> must exist. The coercion will work by coercing the Bar<T> field into Bar<U> and filling in the rest of the fields from Foo<T> to create a Foo<U>. This will effectively drill down to a pointer field and coerce that.

It appears that PhantomData fields are ignored for the purpose of coercion.

[petertodd]

Note how a SliceLen<T> would be the ideal metadata for a [T] slice, as it could express the fact that the range of valid lengths for a slice reference depends on the size of T.

However, as there's quite a few ways of manipulating slice pointers without unsafe, eg via ptr::slice_from_raw_parts, I don't know if such types can actually enforce all that much at compile time.

[SimonSapin]

there's quite a few ways of manipulating slice pointers without unsafe, eg via ptr::slice_from_raw_parts

Yes that’s the idea behind this RFC: generalize slice_from_raw_parts to other kinds of DSTs

[Manishearth]

So a thing that seems to be missing here is a stable layout for DynMetadata itself.

A really annoying thing is that currently you cannot opaquely pass trait objects across FFI without doing a second allocation, because Box<dyn Trait> has unknown layout. Are there plans to make this feasible? To me this has been the main use case for work on DST APIs

[SimonSapin]

Would it make sense to add conversions between DynMetada and some raw pointer type? Would that help the FFI use case?

[Manishearth]

Yes, it would. It would be annoying to use, but it would suffice.

[Manishearth]

Doesn't even need to be a pointer type, jsut an opaque type with a well-defined layout. Though pointers makes it easier for other tools to use, definitely.

[SimonSapin]

We could document that DynMetadata itself has pointer size and ABI. (And introduce some other metadata type if there’s ever a new kind of DST that needs something else.)

[Manishearth]

We could document that DynMetadata itself has pointer size and ABI. (And introduce some other metadata type if there’s ever a new kind of DST that needs something else.)

That would be nice, and it would be nice if it had explicit conversion functions to *const !

[SimonSapin]

*const (), sure, why not.

A *const ! pointer though would always be UB to dereference. So it… encodes in the type system that it is always dangling? That doesn’t seem a good fit for vtables.

[Manishearth]

That works too yeah

[RalfJung]

It was brought to my attention that this feature has some very subtle interaction with unsafe code. Specifically, the following function is currently sound in the sense that safe code cannot cause any UB even when it calls this function:

pub fn make_weird_raw_ptr() -> *const dyn Send {
    unsafe { std::mem::transmute((0x100usize, 0x100usize)) }
}

This RFC is a breaking change in that it makes the above function unsound:

let ptr = make_weird_raw_ptr();
let meta = metadata(ptr);
let size = meta.size(); // *oops* UB

At the very least, this should be listed as an open concern to be resolved.

Maybe metadata should only be safe on references, not raw pointers?

[RalfJung]

Should DynMetadata not have a type parameter? This might reduce monomorphization cost, but would force that the size, alignment, and destruction pointers be in the same location (offset) for every vtable. But keeping them in the same location is probaly desirable anyway to keep code size small.

Don't size and align already have to be in the same location? Certainly Miri assumes this in its implementations of size_of_val and align_of_val for trait objects -- and I don't see a way to implement this without that information being at a consistent location.

For drop, I don't understand why it is mentioned here as also having to be in the same location.

[petertodd]

Re: operate on references, `Weak<T>` needs to be able to get a layout for a dropped value to deallocate memory. So what we probably want is a `MaybeDropped<T>` wrapper to represent a type whose value may have been dropped, and have `metadata` operate on it. `MaybeDropped` can be implemented as a wrapper around `ManuallyDropped` that prohibits (safe) access to the inner value.

…

On March 13, 2021 6:01:58 AM EST, Ralf Jung ***@***.***> wrote: It was [brought to my attention](rust-lang/unsafe-code-guidelines#166 (comment)) that this feature has some very subtle interaction with unsafe code. Specifically, the following function is currently *sound* in the sense that safe code cannot cause any UB even when it calls this function: ```rust pub fn make_weird_raw_ptr() -> *const dyn Send { unsafe { std::mem::transmute((1usize, 1usize)) } } ``` This RFC is a breaking change in that it makes the above function *unsound*: ```rust let ptr = make_weird_raw_ptr(); let meta = metadata(ptr); let size = meta.size(); // *oops* UB ``` At the very least, this should be listed as an open concern to be resolved. Maybe `metadata` should only be safe on references, not raw pointers? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #81513 (comment)

[SimonSapin]

@RalfJung Yes, this is an important point. It came up in RFC discussions but I forgot to incorporate it in unresolved questions then. I’ve done so in the issue description here.

My understanding was that make_weird_raw_ptr is sound in current compilers but that related language rules are still mostly undecided. Has that changed?

Don't size and align already have to be in the same location?

I’m also skeptical that it could be any other way, this point is mostly copied from a comment on the RFC

Maybe metadata should only be safe on references, not raw pointers?

I think that would be a serious limitation. I don’t see a reason extracting the components of any raw pointer and putting them back together shouldn’t be sound.

However if we end up deciding that raw trait object pointers shouldn’t have any validity invariant for their vtable pointer then DynMetada methods like size could be made unsafe fns.

[RalfJung]

I’ve done so in the issue description here.

Thanks. Notice however that for this RFC to work, it is not required to make "valid vtable" part of the validity invariant. Making it part of the safety invariant would be sufficient, since this is a library-level concern.

My understanding was that make_weird_raw_ptr is sound in current compilers but that related language rules are still mostly undecided. Has that changed?

Indeed, neither the validity invariant nor the safety invariant of raw pointers are pinned down exactly. I think it is safe to say though that people would expect these invaraints to be as weak as is at all possible, i.e., to require as little as possible. Even the fact that the vtable pointer is non-NULL is tripping people up and we might want to change that.

size_of_val_raw and similar APIs are unsafe fn for this exact reason.

However if we end up deciding that raw trait object pointers shouldn’t have any validity invariant for their vtable pointer then DynMetada methods like size could be made unsafe fns.

That would be another option, yes. (There could also be SafeDynMetadata as the metadata of dyn Trait references where these methods could still be safe.)

[Rua]

Is there a reason why these functions are not const?

[WaffleLapkin]

@Rua most functions described in the tracking issue are const. If you are talking about DynMetadata::{size_of,align_of,layout}, then no, I think those could be const and I don't see a reason why they are not yet other than "no one bothered to implement the intrinsics in CTFE".

[Rua]

Hmm strange, they are shown as const here, but not in the Rust documentation:
https://doc.rust-lang.org/std/ptr/fn.from_raw_parts.html

[slanterns]

Maybe it's just because the UI is a bit... confusing.

And like https://doc.rust-lang.org/std/ptr/fn.copy.html, the function signature will not show const if it is const-unstable.

[dead-claudia]

Created #125511 to track that rustdoc bug, so it doesn't pollute this issue any longer.

[dead-claudia]

Just filed an API question related to this: #125517

[JohnDowson]

Has there been any progress on stabilizing this feature over the last year, perhaps in the depths of zulip?

[nikomatsakis]

So...I'm dropping a line here because I've realized that I would like to leverage this trait as a better name for Unsized in a design like this one. Given that it's still unstable this seems achievable.

[Rua]

I think #125517 needs to be looked at before anything is stabilised here. Either that, or stabilise only for dyn but leave slice metadata open?

[Kixunil]

@nikomatsakis good point and I strongly suspect this also ought to have a way to implement custom DynSized because CStr claims it wants to become a thin pointer in the future (with extern types I suppose) but because it currently isn't its size can be dynamically calculated and people might be relying on it.

[traviscross]

Note that the naming of the APIs here would be affected by the ongoing proposed FCP in:

• Decide on name for derive(SmartPtr) #129104

[RalfJung]

Over here, @HeroicKatora suggested some functions that would belong in this tracking issue. In slightly adjusted form, those would be:

impl<T: ?Sized> *const T {
    pub fn metadata(self) -> <T as Pointee>::Metadata;
    pub fn with_metadata<U: ?Sized>(self, other: <U as Pointee>::Metadata) -> *const U;
}

impl<T: ?Sized> *mut T {
    pub fn metadata(self) -> <T as Pointee>::Metadata;
    pub fn with_metadata<U: ?Sized>(self, other: <U as Pointee>::Metadata) -> *mut U;
}

Also of note is rust-lang/libs-team#246 which would replace all <T as Pointee>::Metadata in all these functions with Metadata<T>, and thus would avoid exposing the Pointee trait.

[RalfJung]

Also, this comment in the tracking issue is not quite accurate:

Right now, there is some inconsistency here: size_of_val_raw(ptr) is unsafe, but metadta(ptr).size_of() does the same thing and is safe.

size_of_val_raw must be unsafe because it can be used on slices where it is possible, in safe code, to create raw slices whose size computation overflows. metadta(ptr).size_of() only works for dyn Trait pointers, thus avoiding the problem. So I don't think this is inconsistent.

By now it is clear that the safety invariant of a dyn trait raw pointer requires vtable validity. So metadta(ptr).size_of() being safe is entirely justified.

[RalfJung]

In fact, metadata(ptr).size_of() is different in another way:

#![feature(ptr_metadata)]
struct S<T: ?Sized> {
    x: i32,
    y: T,
}

fn main() {
    let x = S { x: 0, y: 0 };
    let xref: &S<dyn Send> = &x;
    dbg!(std::ptr::metadata(xref).size_of()); // 4
    dbg!(std::mem::size_of_val(xref)); // 8
}

DynMetadata::size_of just returns the size of the dyn part, even when it is the metadata of a pointer that has a prefix before the dyn part!

At the very least, this needs to be more clearly documented. But I think ideally we'd not provide a size_of method with such confusing behavior.

[joshlf]

TL;DR: Pointee is very useful and should be stabilized. It would be good if, for slice DSTs, it added the ability to extract the byte offset of the trailing slice field and the size of the trailing slice's element type.

I'd like to provide some (not-so-prior) prior art and use cases. I hope that this motivates that it'd be very useful to stabilize this feature, but also that some changes may be in order (at least to support the use cases described here).

I'm going to be basing these examples on zerocopy 0.8.5, which is at this Git commit.

In zerocopy, we have the KnownLayout trait, which is roughly a polyfill for Pointee. It permits us to make a number of APIs support both sized types and slice DSTs in a generic manner. As an example of this, see FromBytes::ref_from_bytes.

Just like Pointee, KnownLayout has an associated PointerMetadata type. We use it in some bounds to restrict types to those which are slice DSTs (which includes actual slices). Usually, these are APIs which accept an explicit element count for the type's trailing slice field - for example, FromBytes::ref_from_bytes_with_elems.

Here's the full source code of KnownLayout (edited for brevity):

pub unsafe trait KnownLayout {
    /// The type of metadata stored in a pointer to `Self`.
    ///
    /// This is `()` for sized types and `usize` for slice DSTs.
    type PointerMetadata: PointerMetadata;

    /// The layout of `Self`.
    #[doc(hidden)]
    const LAYOUT: DstLayout;

    #[doc(hidden)]
    fn raw_from_ptr_len(bytes: NonNull<u8>, meta: Self::PointerMetadata) -> NonNull<Self>;

    /// Extracts the metadata from a pointer to `Self`.
    fn pointer_to_metadata(ptr: *mut Self) -> Self::PointerMetadata;

    /// Computes the length of the byte range addressed by `ptr`.
    ///
    /// Returns `None` if the resulting length would not fit in an `usize`.
    #[doc(hidden)]
    fn size_of_val_raw(ptr: NonNull<Self>) -> Option<usize> {
        let meta = Self::pointer_to_metadata(ptr.as_ptr());
        // SAFETY: `size_for_metadata` promises to only return `None` if the
        // resulting size would not fit in a `usize`.
        meta.size_for_metadata(Self::LAYOUT)
    }
}

/// The metadata associated with a [`KnownLayout`] type.
#[doc(hidden)]
pub trait PointerMetadata: Copy + Eq + Debug {
    /// Constructs a `Self` from an element count.
    ///
    /// If `Self = ()`, this returns `()`. If `Self = usize`, this returns
    /// `elems`. No other types are currently supported.
    fn from_elem_count(elems: usize) -> Self;

    /// Computes the size of the object with the given layout and pointer
    /// metadata.
    ///
    /// # Safety
    ///
    /// `size_for_metadata` promises to only return `None` if the resulting size
    /// would not fit in a `usize`.
    fn size_for_metadata(&self, layout: DstLayout) -> Option<usize>;
}

Mostly, KnownLayout just polyfills items already exposed by this or other features:

• KnownLayout::PointerMetadata is like Pointee::Metadata
• KnownLayout::raw_from_ptr_len is like core::ptr::from_raw_parts
• KnownLayout:: pointer_to_metadata is like core::ptr::to_raw_parts
• KnownLayout::size_of_val_raw is like core::mem::size_of_val_raw

However, there are some items which would be useful to add to Pointee or related APIs:

• PointerMetadata::size_for_metadata is used e.g. here to compute what the size would be of a pointer with the given metadata. This is useful because it avoids needing to synthesize a raw pointer just to call (e.g.) KnownLayout::size_of_val_raw
• PointerMetadata::from_elem_count is used here to construct a type from a usize metadata regardless of whether the type in question is actually a slice DST. This is probably a pretty niche use case.
• KnownLayout::LAYOUT encodes more information about a type's layout than, to my knowledge, Pointee exposes

KnownLayout::LAYOUT is of type DstLayout. Here's the full source code (edited for brevity):

pub struct DstLayout {
    align: NonZeroUsize,
    size_info: SizeInfo,
}

enum SizeInfo {
    Sized { size: usize },
    SliceDst(TrailingSliceLayout),
}

struct TrailingSliceLayout {
    // The offset of the first byte of the trailing slice field. Note that this
    // is NOT the same as the minimum size of the type. For example, consider
    // the following type:
    //
    //   struct Foo {
    //       a: u16,
    //       b: u8,
    //       c: [u8],
    //   }
    //
    // In `Foo`, `c` is at byte offset 3. When `c.len() == 0`, `c` is followed
    // by a padding byte.
    offset: usize,
    // The size of the element type of the trailing slice field.
    elem_size: usize,
}

This contains two pieces of information that Pointee does not expose for slice DSTs:

• The offset of the trailing slice field
• The element size of the trailing slice field

These are needed in order to implement validate_cast_and_convert_metadata, which is what enables us to support unsized types in methods like FromBytes::ref_from_bytes. validate_cast_and_convert_metadata validates that a particular memory range could hold a particular T: ?Sized + KnownLayout (it satisfies T's alignment and is a valid size for T). On success, it computes the correct pointer metadata to describe a T at that memory range.

In order for zerocopy to replace KnownLayout with Pointee, we would need Pointee to provide these two pieces of information.

---

EDIT: It may also be useful to support slicing slice DSTs.