There should be a way to make a type as "stably a 1-ZST" for repr(transparent) purposes

[RalfJung]

Currently, if one crate defines a 1-ZST with private fields, and then another crate tries to use that in a repr(transparent) type, that produces an error:

// Crate A
pub struct MyMarkerType((());

// Crate B

#[repr(transparent)]
struct Transparent(i32, A::MyMarkerType);

This warning is caused by #78586. The intention of the warning is to guard against a semver hazard: if crate A adds non-zero-sized fields to MyMarkerType in the future, that would break compilation of crate B.

However, what if crate A actually wants to promise that it will never add such fields? Currently it has no way to express this, the lint will always fire for types with private fields in other crates. This is on track to becoming a hard error (#78586).

See here for where @CAD97 originally brought up this issue: a type like this is defined by the generativity crate.

[hanna-kruppe]

There is a workaround available today, though it's a bit annoying: for every 1ZST token type Tok that you define and want other crates to be allowed to include in repr(transparent) wrappers, define:

#[repr(transparent)]
pub struct WithTok<T>(pub T, pub Tok);

Then downstream crates that want to put multiple such tokens in their own repr(transparent) wrappers can replace this:

#[repr(transparent)]
struct Wrapper<T>(T, lib1::Tok1, lib2::Tok2);

with this:

#[repr(transparent)]
struct Wrapper<T>(lib1::WithTok1<lib2::WithTok2<T>>);

This is a lot of boilerplate to construct and access, but it maintains the property that Wrapper<T> is a transparent wrapper around T, gives access to the token values in case they're non-trivial to construct, and reduces the API commitment problem to documenting that the various WithTok<T> types are transparent wrappers around T (which is less tricky when the fields are public).