Replace `feature(layout_for_ptr)` with `feature(layout_for_meta)`

[CAD97]

Proposal

Problem statement

Tracking issue: rust-lang/rust#69835

Current unstable API

// core;:mem
unsafe fn size_of_val_raw<T: ?Sized>(val: *const T) -> usize;
unsafe fn align_of_val_raw<T: ?Sized>(val: *const T) -> usize;

// core::alloc::Layout
unsafe fn for_value_raw<T: ?Sized>(t: *const T) -> Self;

Proposed unstable API

// core;:ptr
unsafe fn size_for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> usize;
unsafe fn align_for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> usize;

// core::alloc::Layout
unsafe fn for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> Self;

(bikeshed away)

Motivation

Per T-lang, these APIs fit nicely into the general story of ptr_metadata. The metadata is currently all that is required to calculate pointee layout, and there are potential language issues with allowing layout calculation to access the data pointer.

Solution sketches

See above for the proposed unstable API change.

Alternatively, the ptr_metadata APIs could all be adjusted to deal in a ptr::Metadata<T> wrapper type (c.f. rust-lang/rust#97052), and then size_of/align_of/layout methods could be provided like they are for DynMetadata. Unfortunately, they cannot be made (infallibly) safe, because it is perfectly safe/acceptable to cast raw pointers such that their metadata/type combo describes a pointee larger than the address space.

The former is the smaller change. The latter is potentially a more coherent design.

Of course, just providing all of the entry points is also an option.

Links and related work

• Implement pointee metadata unsizing via a TypedMetadata<T> container rust#97052 : proposes a ptr::Metadata<T> type for the purpose of coercions, which cannot be provided for <T as Pointee>::Metadata
• Tracking Issue for layout information behind pointers rust#69835 : layout_for_ptr tracking issue
• Tracking Issue for pointer metadata APIs rust#81513 : ptr_metadata tracking issue
• Note design constraints on hypothetical DynSized lang-team#166 : describes what support for custom pointee layout might look like
• Experiment: Make intrinsic::size_of(slice) saturate rust#95832 : experiment to partially measure the cost of a fallible metadata -> Layout conversion

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[m-ou-se]

This seems to assume the size of the object can fully be determined by the metadata, without the object pointer. But don't we want to support custom dynamically sized types in the future, like a thin &CStr, where the pointer part is necessary to determine the size? How would that work?

[joshtriplett]

Also, it sounds like this ACP is referencing that lang team design note to say that there are problems with having types that require reading the pointee to get the size, but with my lang hat on, I don't understand how that note implies such problems.

[Amanieu]

We discussed this in the libs-api meeting today and decided not to accept this for several reasons:

• The proposed API doesn't work with type inference and forces you to write a turbofish.
• The proposed API may not have enough information to work with custom DSTs like thin CStr pointers.

[Amanieu]

Slight correction: actually this would work with custom DSTs, however the first point still stands so it doesn't make sense to remove the old API.

[CAD97]

Makes enough sense to me. AIUI these API may potentially make sense in addition to the *_of_val_raw functions, but don't logically want to replace those functions.

I don't see the requirement of a turbofish as too odd, since the sized *_of versions also require a turbofish, but the point about wanting API that works with read-requiring DST makes sense.

I might make a more constrained ACP once I've wrapped up some of my open work (I still think that a type level guarantee of no pointer access is highly useful, i.e. MetaSized vs DynSized), but that's for later when I make a new push for my ideas on supporting exotically sized types. (Actually, it'd probably be more of an MCP tbh.)

(Notably, *_for_pointee could plausibly be made safe, whereas *_for_val_raw cannot.)