You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently 3 types of (de)serialization functions:
fn deserialize(bytes: <Something>::Serialization) which is used for Scalar, Field, and Signature types and wrappers
fn deserialize(bytes: &<Something>::Serialization) same as the previous, but with a reference
fn deserialize(bytes: &[u8]) which is used for all other structs
The obvious inconsistency is between 1 and 2. I was changing all of them to take a reference (option 2) but thinking about it, I wonder if we should make them all follow option 3.
The <Something>::Serialization seems like an implementation detail which users shouldn't need to handle. Currently, to deserialize e.g. an identifier you need something like
which is super annoying. The user needs to lookup what the <<C::Group as Group>::Field as Field>::Serialization type is, and figure out that they have to use TryFrom<Vec<u8>>.
If we changed to option 3 in the public API (while still using <<C::Group as Group>::Field as Field>::Serialization internally) then they just have to pass a &[u8] which is more straightforward.
The text was updated successfully, but these errors were encountered:
There are currently 3 types of (de)serialization functions:
fn deserialize(bytes: <Something>::Serialization)
which is used for Scalar, Field, and Signature types and wrappersfn deserialize(bytes: &<Something>::Serialization)
same as the previous, but with a referencefn deserialize(bytes: &[u8])
which is used for all other structsThe obvious inconsistency is between 1 and 2. I was changing all of them to take a reference (option 2) but thinking about it, I wonder if we should make them all follow option 3.
The
<Something>::Serialization
seems like an implementation detail which users shouldn't need to handle. Currently, to deserialize e.g. an identifier you need something likewhich is super annoying. The user needs to lookup what the
<<C::Group as Group>::Field as Field>::Serialization
type is, and figure out that they have to useTryFrom<Vec<u8>>
.If we changed to option 3 in the public API (while still using
<<C::Group as Group>::Field as Field>::Serialization
internally) then they just have to pass a&[u8]
which is more straightforward.The text was updated successfully, but these errors were encountered: