Maybe this is not the most important issue for serde, but correct usage
here can help users use PhantomData correctly in general.
We want to use PhantomData<fn() -> T> when we are producing, not
owning values of T.
(1) PhantomData<T> and (2) PhantomData<fn() -> T> have the same variance
implications, but differ in other aspects. (1) makes the type non-Send
if T is non-Send. (2) is always Send + Sync.
PhantomData is supposedly simple to reason about (this is at least the
idea of their construction): the phantom data should mimic what the type
actually does. Deserialization does actually do the equivalent of fn() -> T, we call a function that returns a T value.
(Further evidence is that we have no field that stores any "T", but we
have a method that returns T or Result<T, _>)
Maybe this is not the most important issue for serde, but correct usage here can help users use PhantomData correctly in general.
We want to use
PhantomData<fn() -> T>when we are producing, not owning values of T.(1)
PhantomData<T>and (2)PhantomData<fn() -> T>have the same variance implications, but differ in other aspects. (1) makes the type non-Send if T is non-Send. (2) is always Send + Sync.PhantomData is supposedly simple to reason about (this is at least the idea of their construction): the phantom data should mimic what the type actually does. Deserialization does actually do the equivalent of
fn() -> T, we call a function that returns a T value.(Further evidence is that we have no field that stores any "T", but we have a method that returns
TorResult<T, _>)