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
In the external tests, for simplicity we use unwrap , the idiomatic way would be to use ? with a from trait for different types of Error enums.
Currently, we allow users to do hash.add(input) however because we can only have a limited amount of inputs, we must return a Result, in case they add more than width-1 scalars. A simpler API would be to just ask the user input a vec![input1, input2,] which would reduce the number of error enums. We could also have both approaches, in case the user does not know all of the inputs before they need to hash and does not want to create temporary values.
One possible change that could be made is to create two structs, one for the solid impl and another for gadget impl, however this will cause a lot of code duplication. Currently, there is one struct and a user will call a struct to indicate whether they want the gadget version or the solid impl
The text was updated successfully, but these errors were encountered:
The first point is more of a nice to have as they are just external tests.
Second point; may just be inevitable unless we only allow users to add input as a vector which is not that user-friendly and will force the user to create a temporary vector if they have another use-case
In the external tests, for simplicity we use
unwrap
, the idiomatic way would be to use?
with a from trait for different types of Error enums.Currently, we allow users to do
hash.add(input)
however because we can only have a limited amount of inputs, we must return a Result, in case they add more thanwidth-1
scalars. A simpler API would be to just ask the user input a vec![input1, input2,] which would reduce the number of error enums. We could also have both approaches, in case the user does not know all of the inputs before they need to hash and does not want to create temporary values.One possible change that could be made is to create two structs, one for the solid impl and another for gadget impl, however this will cause a lot of code duplication. Currently, there is one struct and a user will call a struct to indicate whether they want the gadget version or the solid impl
The text was updated successfully, but these errors were encountered: