Is there a derive macro for DeserializeOwned?

1

I am trying to derive Deserialize for a struct Foo<T:'static+DeserializeOwned+Serialize>{...} but seems I cannot derive Deserialize for somthing that contains generics.
Is there a way to derive DeserializeOwned ?
the error message mentions a struct named LoginCreds which has nothing to do with this and has never been used with these functions. Am i supposed to implement deserialize for every single struct in my app this to work ?

image
image1901×1020 226 KB

2

Does this not work?

#[derive(Serialize, Deserialize)]
struct GenericToken<T> {
    exp: i64,
    data: T,
}

Please do not post images. You are forcing me to rewrite it when giving examples.

1 Like
3

image is mainly for the error message. In question body I also have written one @alice.
In this example the T is not constrained how and why does this work ?

4

The Serialize trait would only be implemented for specific choices of T that implement Serialize.

I also prefer errors in code blocks.

1 Like
5

isnt it what we want I mean what does it mean to implement Serialize for something that is not serialize.
I mean how can GenericToken knows T is serialize unless it is constrained ?

6

It will generate something like this:

impl<T> Serialize for GenericToken<T>
where
    T: Serialize,
{
    ...
}
7

Ah so it is already adding the Serialize Deserialize constraints to it while generating the code

8

Yes. It's the same with e.g. Clone.

#[derive(Clone)]
struct MyStruct<T> {
    my_val: T,
}

You can only clone MyStruct<T> if T: Clone.

9

Thanks.
One last thing tho. Why is it giving me errors about LoginCreds which has nothing to do with this problem ?

10

No idea.

1 Like
11

I saw that today as well where the serde error text were referencing a seemingly different struct than the one that the error was pointing to.

12

TL;DR: it isn't.

When the rust compiler wants to tell you about trait Serialize, it needs to find some path to the trait to name it. When multiple paths are available (such as happens due to serde's derive expansion), it seems to prefer the lexographically first path, rather than what might seem more logical to a human.

The only reason LoginCreds is mentioned is that the compiler happened to pick that path to the trait to mention it.

1 Like
13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.