So, while resolving the memory safety issue of #28 that you pointed out in #27, I had a pause while reaching the implementation of Abomonation for PhantomData.
Currently, abomonation provides an impl of Abomonation for PhantomData<T> even if T is not abomonable. This is by design, as there is a test checking that this impl is available. And it is certainly technically correct to the first order of approximation: since PhantomData contains no data, it is trivially serializable.
Where I get uneasy, though, is when I consider how PhantomData<T> is typically used. By and large, the main use for this marker type in the wild is in container classes like Box and Vec, where you get types which only hold a *mut T, NonNull<T>, or index into some kind of arena of T, but need to tell rustc that they "logically own" one or more Ts, so that Send, Sync, Drop and other stuff that gets automatically implemented works as expected.
From this perspective, if a type contains a PhantomData<T>, it should almost certainly be regarded as containing a T by abomonation too. In which case we should require that this T be abomonable.
So, while resolving the memory safety issue of #28 that you pointed out in #27, I had a pause while reaching the implementation of
AbomonationforPhantomData.Currently, abomonation provides an impl of
AbomonationforPhantomData<T>even if T is not abomonable. This is by design, as there is a test checking that this impl is available. And it is certainly technically correct to the first order of approximation: sincePhantomDatacontains no data, it is trivially serializable.Where I get uneasy, though, is when I consider how
PhantomData<T>is typically used. By and large, the main use for this marker type in the wild is in container classes likeBoxandVec, where you get types which only hold a*mut T,NonNull<T>, or index into some kind of arena ofT, but need to tellrustcthat they "logically own" one or moreTs, so thatSend,Sync,Dropand other stuff that gets automatically implemented works as expected.From this perspective, if a type contains a
PhantomData<T>, it should almost certainly be regarded as containing aTby abomonation too. In which case we should require that thisTbe abomonable.What do you think about this train of thought?