Can't derive for struct with fields of type `T` and `PhantomData<T>`

[progval]

use std::borrow::Borrow;
use std::marker::PhantomData;

use epserde::prelude::*;
use epserde::Epserde;

#[derive(Epserde)]
pub struct OuterStruct<T: AsRef<[u64]>> {
    data: T,
    marker: PhantomData<T>,
}

fn main() {
    let original = OuterStruct {
        data: vec![1, 2, 3],
        marker: PhantomData,
    };

    let mut file = std::io::Cursor::new(vec![]);
    original.serialize(&mut file).expect("Could not serialize");
    let data = file.into_inner();
    let deserialized = <OuterStruct<Vec<u64>, >>::deserialize_eps(&data)
        .expect("Could not deserialize");
}

errors with:

error[E0308]: `?` operator has incompatible types
 --> epserde/examples/borrow.rs:7:10
  |
7 | #[derive(Epserde)]
  |          ^^^^^^^ expected `PhantomData<<T as DeserializeInner>::DeserType<'_>>`, found `PhantomData<T>`
8 | pub struct OuterStruct<T: AsRef<[u64]>> {
  |                        - found this type parameter
  |
  = note: `?` operator cannot convert from `PhantomData<T>` to `PhantomData<<T as epserde::deser::DeserializeInner>::DeserType<'deserialize_eps_inner_lifetime>>`
  = note: expected struct `PhantomData<<T as epserde::deser::DeserializeInner>::DeserType<'deserialize_eps_inner_lifetime>>`
             found struct `PhantomData<T>`
  = note: you might be missing a type parameter or trait bound
  = note: this error originates in the derive macro `Epserde` (in Nightly builds, run with -Z macro-backtrace for more info)

Removing either field fixes the error.

[vigna]

We do something special for PhantomData, and I think we must take care of not doing that something special if T is also a field type.

[vigna]

Ok, that's... complicated. The problem is that PhantomData is treated as a pass-through—if you have a structure with type parameter T and you have a PhantomData<T> inside than you get a deserialized structure with parameter T and a PhantomData<T>, because we cannot assume that T is deserializable, and thus has an associated DeserType.

The problem is that if you now add a field of type T, the type must be deserializable and the deserialized structure will be parameterized by the DeserType of T, not by T. But you'll still get PhantomData<T>, as it is a pass-through.

I don't think we can fix this simply by having PhantomData of the DeserType of T in the structure, because T might be a marker type of some kind and you might not want to change it.

And we cannot introduce a new type parameter TT either, as we really want to return the same structure.

Also, having a marker type if you have the type in the structure is redundant, but that's not the point.

[vigna]

So maybe the first question is: why do you want to do this? And the second question is: given that, what result would you expect/desire?

[vigna]

Also, I really don't see how to have PhantomData of the DeserType, as this choice is hard-coded in the associated type of the DeserializeInner implementation for PhantomData. So maybe a nicer error is all we can do.

[progval]

So maybe the first question is: why do you want to do this? And the second question is: given that, what result would you expect/desire?

I found this while trying to minimize the example in #48 (comment), where I needed the PhantomData because T is actually a parameter of an other type, and does not actually appear in the struct

[vigna]

The only solution coming to my mind now is a custom PhantomDeserData<T> that just wraps a PhantomData<T>, but whose DeserType is PhantomDeserData<T::DeserType>. And you use it in these situations. Does not solve the problem if types over which you have no control contain PhantomData, tho.

[vigna]

Of course, PhantomDeserData<T> has a bound T: DeserializeInner, contrarily to PhantomData.

[vigna]

@zommiommy, @progval, thoughts?

[progval]

why can't PhantomData<T>'s DeserType be PhantomData<T::DeserType>?

[vigna]

As I said,

impl<T: ?Sized> DeserializeInner for PhantomData<T> {

we do not have that. PhantomData must be usable with any type.

[vigna]

If you use, for example, the type as a selector it might not be serializable, and in fact you might have no control over its serializability.

[progval]

Hmm... Whould a field annotation in the derive macro work? For example:

struct MyStruct<Data: AsRef<[u8]>, T> {
    array: Data,
    #[epserde(deser_type(PhantomData<T::DeserType>))]
    marker: PhantomData<T>,
}

to make MyStruct's implementation deserialize to PhantomData<T::DeserType> instead of PhantomData<T>

Speaking of field annotations, I have an other use for them (but out of scope for this issue):

struct MyStruct<Data: AsRef<[u8]>> {
    big_array: Data,
    #[epserde(deep_copy)]
    small_string_i_dont_mind_deepcopying: String,
}

[vigna]

Mmmhhhh... I guess we could intercept that for PhantomData and change the type. It would pollute nontrivially the derive code because we'd have to check each time we go through the fields whether it's a PhantomData and we have the annotation.

For the second annotation: yes, I think it is doable.

[vigna]

I tried to have Augment write the annotation, and after three trials he implemented a DeserPhantom type instead as a better solution. Also, I really don't see any particular advantage of the annotation—you have to write a specific syntax anyway...