Bikeshed request: `struct(<T as Pointee>::Metadata)`

libs
1

TL;DR:

// std::ptr
struct 🚲<T: ?Sized>(pub <T as Pointee>::Metadata);
impl<T: ?Sized + Unsize<U>, U: ?Sized> CoerceUnsized<🚲<U>> for 🚲<T> {}

What should 🚲 actually be called?

(How is it different from <T as Pointee>::Metadata? The T type is reattached to the "strong type alias" / newtype.)

Suggestions so far, unordered:

  • JustMetadata<T>
  • TypedMetadata<T>
  • MetadataOf<T> (or some other predicate)
  • ptr::Metadata<T>
  • PointeeMetadata<T>
2

Is the plan to give this type DispatchOnDyn, too, so that we’ll eventually get the ability to do fn foo(self: 🚲<T>) methods in object safe traits?

I’m asking because finding the right name can make more sense if you have a feeling of the typical use-cases where you’d encounter it.

Regardless of whether or not the use-case I asked about above is going to be possible, what are possible β€œtypical” use-cases in your opinion?

3

Since the PR finds it most natural to call it "the pointee metadata", and it's the Metadata of the Pointee, PointeeMetadata makes a lot of sense

4

seems reasonable; if it's going to be in std::ptr, I see no compelling reason for a longer name. For other examples of names that rely on the reader knowing where they're coming from in order to make sense of them, consider std::cell::Ref, std::ptr::eq or std::iter::Map.

Of course, if people are going to be using it in a context where they have other Metadatas floating around, they can always use it as PointeeMetadata or whatever.

3 Likes
5

Β―\_(ツ)_/Β― I haven't thought about that too much. It'd be an interesting way to support associated trait functions... though this would I think live on DynMetadata, not 🚲, which is for any pointee.

The typical (and perhaps only?) use-case is talking a normal (potentially fat) pointer, calling to_raw_parts, and then storing the pointer in decomposed form. This is most beneficial when doing something like the Storage API abstracts over, where you don't store the data pointer directly but rather some key information which allows you to retrieve the data pointer.

It's growing on me, especially if the other ptr_metadata APIs are adjusted to return it rather than it just being a wrapper you use to get CoerceUnsized.

6

We have two things to name here: 1. metadata that has the pointee type included, and 2. metadata that exclude it.

When I see JustMetadata, my perception is that it refers to 2 (so it's just the metadata, without any extra type information). When I see TypedMetadata, my inpression is that it refers to 1.

I think we could either:

  • Name 1 Metadata (and modify ptr::metadata to return this) and 2 ErasedMetadata or JustMetadata (and function returning the later will be ptr::just_metadata or something similar), and
  • Name 1 TypedMetadata and 2 Metadata, and the function returning the former will be ptr::typed_metadata.

Personally I think the first option is better, but it might cause more monomorphization?

7

ptr::metadata::<T> is always monomorphized over T, as is even <T as Pointee>::Metadata. I don't think returning ptr::Metadata<T> will change the amount of monomorphized code written.

The latter is <T as Pointee>::Metadata. While std could include a type alias for this, I don't think it necessary, and it'd only serve to increase the "what's the difference" between the transparent alias and the retyped newtype.

8

We need a name for it even if we don't include an type alias for it, e.g. for naming the function that returns it.

9

Currently, that'd just be ptr::metadata(pointer).0 if ptr::metadata::<T>(*const T) -> ptr::Metadata<T>.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.