Extend #[derive(TransparentWrapper)]

[zachs18]

(Based on PR 146, but not particularly related)
Allow types more complicated than single idents in #[transparent(Type)] when deriving TransparentWrapper.

• It still does string comparison, because resolving type equality is not possible in a proc-macro.
• This is valid as long as there is no way to make the same token stream/source string refer to different types in the struct definition and the derived impl, which I believe is the case.
  • Maybe some unnamed const or function could be emitted to ensure the two types are actually the same at compile-time? like const _: () = { fn _detail<Generics>(x: (Type1, Type2), _generic_use: PhantomData<Struct<Generics>>) -> (Type2, Type1) { x } };

TODO: think about and verify that variance cannot break things.

[zachs18]

Since users can in most cases just do like

type Wrapped = Complex<Type>;
#[derive(TransparentWrapper)]
#[transparent(Wrapped)]
#[repr(transparent)]
struct MyType {
  wrapped: Wrapped,
  etc: ZST,
}

I'm not sure if this is worth the trouble. Except I guess complex types involving generics are not representable without this, e.g.

#[derive(TransparentWrapper)]
#[transparent(Wrapped)]
#[repr([T; 2])]
struct ArrayPair<T> {
  wrapped: [T; 2],
  etc: ZST,
}

[Lokathor]

#[repr([T; 2])]?

[zachs18]

Typo

#[derive(TransparentWrapper)]
#[transparent([T; 2])]
#[repr(transparent)]
struct ArrayPair<T> {
  wrapped: [T; 2],
  etc: ZST,
}

[fu5ha]

weird formatting

[zachs18]

Formatting fixed.

For the semantics of this section though, we might want to allow a trailing comma here. As-is, this rejects #[transparent(T, )], which might be useful if T is long and would naturally spill onto another line.

Also, if the parsing of the transparent helper fails, the code falls back to the "find the one field" strategy, e.g. this succeeds:

#[derive(bytemuck::TransparentWrapper)]
#[repr(transparent)]
#[transparent(not a type)]
struct Foo {
 one_field: u32,
};

which is not ideal. Maybe get_type_from_simple_attr should bail if it finds the attribute but fails to parse it?

[fu5ha]

We could suggest the type alias workaround here as well.

[Lokathor]

released in the 1.10.2 version of the derive crate.