I'm a little bit worried when I see Vec<_> anywhere

I tried to write generic group and field [de]serialization code, and then reuse it for the specific G1, G2, Fr and Fq. The generic code can't make assumptions about the length.

But I found a better solution for the fields, at least, since the bytes in FrRepr and FqRepr are public anyway.

For the groups it's not that easy, though, since [u8; 48] doesn't implement Serialize and Deserialize (the standard impls go only up to 32 and there's still no nice solution). I agree that it's annoying to waste eight (four?) bytes on the length of a constant-length array. But the only solution I can think of is to basically duplicate serde's own implementation for arrays. I'm happy to do that; what do you think?

I'd also like to require e.g. PrimeField: Serialize + for<'r> Deserialize<'r>, so that users can use serialization even in a generic E: Engine context. But since it's feature-gated I don't know if that's possible without duplicating the whole trait definition.

I've been busy travelling but this PR is on my TODO list.

Two things:

1. We're splitting the field definitions and stuff away from this crate and into a separate crate called ff. See Use ff crate for traits and impls #90 for more information.
2. One thing that's weird about adding supertraits to PrimeField or PointRepresentation based on a crate feature is that Rust features are supposed to only augment the API, whereas adding bounds to a trait is a reverse-incompatible change. I don't think we can use a Sealed trick to avoid this problem.

It seems like it would be better to implement a wrapper around the types pairing provides and implement serialization for that stuff, rather than trying to build a generic interaction between these traits and serialization capabilities. The wrapper might even be more ergonomic to use downstream.

I agree, the conditionally compiled trait bounds were a bad idea.

Yes, we're currently using a wrapper. Another option is providing a serialization module for #[serde(with = "module")].

I still think the most convenient and straightforward way to provide serialization is to implement the serde traits directly for the types themselves. But feel free to close this PR if you'd prefer one of the other approaches. I'm happy to try and implement them.

The Rust API guidelines also recommend to just implement Serialize and Deserialize for the types directly, possibly behind a feature gate.

☔ The latest upstream changes (presumably #90) made this pull request unmergeable. Please resolve the merge conflicts.

I resolved the merge conflict. Please let me know if you want me to make any other changes.

Can you add Serialize and Deserialize to Fq12? This is very useful in IBE.

For that it would be really convenient to use serde_derive. But then the feature can't be called serde anymore, I think. Which do you prefer:

• You need to enable both features serde and serde_derive to get a serializable Fq12 (and Fq6 and Fq2).
• Keep only serde and manually implement serialization for Fq12, too, which is a bit more complex than deriving it. (Slightly more code, but maybe not too bad.)
• Rename the feature, e.g. use-serde = ["serde", "serde_derive"].
• No feature: always support (and depend on) serde.

Serde has a feature "derive" which exposes the serde_derive macro from within serde itself; maybe that can help?

You're right, thanks! I added it.