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
Kudos on this really interesting crate. It fits my needs quite well! I noticed, however, that this crate depends on rand. I like to keep my dependencies as small as possible, and rand is a particularly heavy crate (112kB!) that has a lot of bells and whistles.
Unless there's a particular need for advanced and cryptographically secure random numbers, would it be possible to drop the dependency on rand? Perhaps a simpler (non-secure) alternative like simplerand could be used. If that's not possible, maybe the random functionality can be hidden behind a feature flag?
Thanks!
The text was updated successfully, but these errors were encountered:
Using just my phone I don't see where it's needed. I'd welcome a pull request to remove the dependency or if needed change it to a dev-dependency. Or I'll try to get to this within a week or two.
Sorry that last comment was false. I forgot that I use random numbers when expanding the hash table in order to give some protection against collision attacks. I doubt we need high quality random numbers for this, and it's not needed at all for many use cases. Maybe a no-rand feature flag would be simplest?
Hello,
Kudos on this really interesting crate. It fits my needs quite well! I noticed, however, that this crate depends on
rand
. I like to keep my dependencies as small as possible, andrand
is a particularly heavy crate (112kB!) that has a lot of bells and whistles.Unless there's a particular need for advanced and cryptographically secure random numbers, would it be possible to drop the dependency on
rand
? Perhaps a simpler (non-secure) alternative like simplerand could be used. If that's not possible, maybe the random functionality can be hidden behind a feature flag?Thanks!
The text was updated successfully, but these errors were encountered: