struct S<T, U, V>(T, U, PhantomData<V>);
transmute::<&S<A, B, C>, &S<A, B, D>() sound?
for<T> PhantomData<T> is a 1-ZST and is therefore ignored for layout purposes)
I'm quite sure that transmute doesn't follow from our current guarantees for struct layout. It's not one of the special cases where we say anything other than "nothing is guaranteed, not even determinism"
But clearly this kind of transmute is extremly useful for some uses of phantom types and requiring repr(C) on those aggregates has big downsides so IMO we eventually need some way to make this work while still getting e.g. automatic struct reordering for reducing padding