Artyom Pavlov

I am a bit hesitant to add such functionality to `cpufeatures`. As I see it, the crate is about runtime-by-default _target feature_ detection, while arithmetic backend width will be completely...

Sorry for the late reply! I will try to take a look at this in the following weeks. We have plans for completely rewriting the current blake2 implementation and I...

I don't think it's an area of responsibility for `zeroize`. Arguably, you should use the [`opaque-debug`](https://docs.rs/opaque-debug) crate or add a manual opaque `Debug` implementation for your type which gets wrapped...

I agree that we probably should start with the fixed output size traits and work on improving our traits after that. As for API design, `XofMac` as a convenience wrapper...

I wonder why the implementation simply does not use `CHUNK_SIZE` for block size.

Sounds interesting. Feel free to open a PR. But I don't think we should use `(__m512i, __m512i)` for the hash state. Instead we should keep `[u64; COLS]`, use unaligned loads,...

I don't think I like this approach. It feels really hacky to me. What exact problem are you trying to solve? Building/testing on `no_std` targets?

I had a more fundamental question: why exactly do you want to make dependency on `getrandom` optional? If you want a way to change entropy source (e.g. for deterministic testing),...

>it broke no_std as the automatic target selection of getrandom looks very arcane Do you perhaps mean the `custom` backend? For most targets supported out-of-box automatic selection is a pretty...

>rather than assuming getrandom is always available. `getrandom`'s _raison d'etre_ is to provide "system randomness" source. If we need "system randomness", then it's better to simply assume that `getrandom` exists...