-
Notifications
You must be signed in to change notification settings - Fork 16
Better UX for constant output function for Sel.Hashing #105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm OK either way: I don't really feel this is confusing or less readable. |
Also, if the presence/ absence of key changes semantics too much, then maybe two functions would work better by not conflating different operations. That being said:
|
@divarvel Well, the change of semantics is "same input gives same output", which makes sense when one has been diving into this kind of API for a while. Not sure about outsiders though. |
It appears that the Blake2 paper uses "Keyed" |
Uh oh!
There was an error while loading. Please reload this page.
Sel.Hashing
uses aMaybe HashKey
parameter tohashByteString
.However this is not fantastic in terms of readability.
I'd like to avoid Maybe-blindness by having a sum type like
data KeyParma = Key <hashkey> | NoKey
(orConstant
).The text was updated successfully, but these errors were encountered: