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
This results in an error because the key type does not match the algorithm family.
This kind of error could be caught at compile time.
My proposal is to change the crate's API to catch this kind of error at compile-time instead of runtime, by moving from an enum-based checking to a type-based system.
Here is an overview of the proposed changes:
Each algorithm family becomes a separated enum.
the Header struct is changed to Header<AF>, taking its algorithm family enum as type parameter, with an algorithm: AF data member.
similarly, the EncodingKey struct is changed to EncodingKey<AF>, with AF recorded in a PhantomData member.
the encode function's signature is changed to something like
With this approach, code using a key for the wrong algorithm family will no longer compile, and we can get rid of some runtime checks.
On the other hand, you can no longer implement FromStr for all algorithms families at once. But since one needs to call a different function to generate the key depending on the algorithm family, I don't think this is a huge problem.
Would you be interested in a PR implementing this proposal?
The text was updated successfully, but these errors were encountered:
Hi!
The current API allows writing encoding code with a key that does not match the algorithm used, e.g.
This results in an error because the key type does not match the algorithm family.
This kind of error could be caught at compile time.
My proposal is to change the crate's API to catch this kind of error at compile-time instead of runtime, by moving from an enum-based checking to a type-based system.
Here is an overview of the proposed changes:
enum
.Header
struct is changed toHeader<AF>
, taking its algorithm family enum as type parameter, with analgorithm: AF
data member.EncodingKey
struct is changed toEncodingKey<AF>
, withAF
recorded in aPhantomData
member.encode
function's signature is changed to something likeWith this approach, code using a key for the wrong algorithm family will no longer compile, and we can get rid of some runtime checks.
On the other hand, you can no longer implement
FromStr
for all algorithms families at once. But since one needs to call a different function to generate the key depending on the algorithm family, I don't think this is a huge problem.Would you be interested in a PR implementing this proposal?
The text was updated successfully, but these errors were encountered: