`derive_where` for serde

[DCNick3]

Would it be possible to support serde derive macros (Serialize & Deserialize) in derive-where?

Currently, if you put fields from associated types, you have to manually put #[serde(bounds(serialize = "XXX: Serialize", deserialize = "XXX: Deserialize<'de>"))], which can amount to a lot of boilerplate, and might not even be possible to generate in declarative macros (at least I didn't find any way to).

To not reimplement the whole serde in this crate, you can just emit the corresponding #[serde(bounds)] and hand off the rest to the upstream derive macro

[daxpedda]

To not reimplement the whole serde in this crate, you can just emit the corresponding #[serde(bounds)] and hand off the rest to the upstream derive macro

We talked about this a long time ago and our main reason not to do this was that reimplementing Serde would be an ungodly amount and error-prone work. But just emitting the corresponding attributes might be reasonable.

I would have to take a deeper look, but in favor.

[ModProg]

It doesn't sound too bad to do, and you are probably right that it wouldn't be possible to emit serde's syntax with declarative macros, because string concatenation only works in certain positions (like the built-in doc attribute).

[DCNick3]

I tried implementing this as part of derive-where, but a big chunk of the code is coupled tightly to generating actual impl blocks, not emitting attributes. I am not familiar with the codebase, so I was not able to come up with a localized API change that would work here

[ModProg]

@daxpedda, how would you want to do this syntactically, should we use the name Serialize and Deserialize I'm slightly opposed as they are not std traits, on the other hand it is unlikely we will add support for a different serialization crate, so I could be swayed here.

Alternatives I've considrered:

• require qualified path, i.e. serde::Serialize and serde::Deserialize
• invent a new name SerdeSerialize, SerdeDeserialize
• just call it Serde and have it only generate the bounds, i.e. not generate the #[derive(Serialize)]
• or just go with Serialize and Deserialize and we'll figure this out should we get any problems.

I was also thinking that we might be able to use FQN as a pattern to replace the crate parameter, i.e. allow you to put any path you want in front of a trait... (my_zeroize::Zeroize).

[DCNick3]

If it's of any use, you can see my standalone implementation of this approach here (it's pretty simple though).

[daxpedda]

I'm in favor of sticking with the same strategy we applied to Zeroize. So we only accept Deserialize and Serialize. By default we use the path serrde::De/Serialize, but users can supply De/Serialize(crate = serde_), same as with Zeroize.

[ModProg]

Probably a good idea to stick with what we have for now, but maybe we can revisit the FQN for crate in the future, there are probably still some open questions with it anyway.