zvariant: Type will fail silently if using with serde skip_serializing

[zeenix]

In GitLab by @zhangyuannie on Dec 18, 2022, 08:03

See also https://serde.rs/field-attrs.html#skip_serializing

Ideally serde's features should work. Otherwise panicking could be very helpful to let the user know this feature is not supported with Type.

For skip_serializing and skip_serializing_if specifically, I believe this is due to serde not serializing the given field while Type produce a signature with the skipped field, which I don't see an easy way to fix.

skip_deserializing probably have similar issue.

[zeenix]

Doesn't #35 and #85 already cover this?

[zeenix]

Ideally serde's features should work. Otherwise panicking could be very helpful to let the user know this feature is not supported with Type.

If we could read Serialize macro's attributes from Type, we can just support serde's attributes and do the right thing. I don't think that's possible.

[zeenix]

In GitLab by @zhangyuannie on Dec 18, 2022, 23:55

#35

I may have missed it but I didn't see this mentioned in the docs. 😅

#85

seems to be more about the TypeDict use case. I'm trying to ask for the Type macro to simply fail if it reached something unsupported, unlike right now where no warning is emitted.

If we could read Serialize macro's attributes from Type

My bad, I'm not too familiar with syn, I thought it is possible as proc macro works on tokens. In this case, feel free to close this issue. 😄

If doable, it would be awesome if something could be happening to indicate something went wrong. Thanks for taking the time.

[zeenix]

#35

I may have missed it but I didn't see this mentioned in the docs.

Oops, this was supposed to be #32.

If doable, it would be awesome if something could be happening to indicate something went wrong. Thanks for taking the time.

As I said, If it's doable, then we can do the right thing and hence there is no warning needed. Keep in mind that I've not actually checked. If it's not doable, then we can't do warning either.

[zeenix]

marked this issue as a duplicate of #32

[zeenix]

marked this issue as related to #32