Deserialize` is not implemented for the type `core::marker::PhantomData<_>`

[logicchains]

This makes it difficult to deserialize structs with phantom types. Serialization also has the same problem but it seems to be avoidable by #[serde(skip_serializing)], so maybe it could be fixed by adding a #[serde(skip_deserializing)], or making skip_serializing also skip deserializing?

[oli-obk]

For a quick hack you can create a wrapper struct around PhantomData and implement Deserialize for that. But I'm not sure if this is ok in the general case. There might be types for which a generated Deserialize or Serialize implementation is wrong. Often PhantomData is used together with raw pointers.

[erickt]

You're right that we need an implementation for PhantomData, but in the meantime, you could also annotate your fields with #[serde(skip_serializing, default)], which should work for you.

[logicchains]

Adding default doesn't seem to help, I still get
the trait serde::de::Deserialize is not implemented for the type core::marker::PhantomData<_>

The code is:

#[derive(Debug, PartialEq, PartialOrd, Eq, Ord, Serialize, Deserialize)]
pub struct ID<T>{
    pub val: i32,
    #[serde(skip_serializing, default)]
    pub phantom: PhantomData<T>
}

[thiagopnts]

I was having the same problem and end up here, anyone found a workaround for this?

[erickt]

Anyone have an opinion on we should serialize this type? Serde impls don't have the ability to say "don't serialize this type" so the best we could do is serialize it as a () and assume someone uses #[serde(skip_serializing)]. For deserialization, we could then deserialize from (), but people could still rely on #[serde(default)] in case the field is not present. What do you all think?

[oli-obk]

well the clean way would be for Serialize impls to be able to optionally not serialize. Like a callback that is called before even the field name is serialized. This would also allow other optimizations like not serializing None fields or () or similar.