Artyom Pavlov

Sounds reasonable. But I wonder whether we should use black- or white-list approach here (i.e. disable for MSVC or enable for GNU and other supported toolchains).

It will depend on progress of [`impl const`](https://github.com/rust-lang/rust/issues/67792), which, unfortunately, does not even has an accepted RFC. In theory we may add inherent const methods, but I would prefer not...

Yes, you are right, currently most crates do not zeroize inner state on drop. IIUC to implement it without hacks we will need either `generic-array` support (e.g. by implementing [`Zeroize`](https://docs.rs/zeroize/0.9.2/zeroize/trait.Zeroize.html)...

@tarcieri Maybe we can transform the whole hash state into byte slice (using `unsafe` code) and call zeroize on it?

I wonder if we should make the reset capability optional... It would allow us to remove the [caching](https://github.com/RustCrypto/hashes/blob/master/blake2/src/blake2.rs#L28-L30) of initial state and thus secret key inside hasher state will be...

I wonder if we should recommend BLAKE3 over BLAKE2. Also I am not sure if we should have both `k12` and `sha3` on the same recommendation list.

I think it will be certainly an interesting (feature-gated?) addition to the `sha-1` crate. We probably don't want to add traits for such scenario, so this functionality will be probably...

We can revisit this question after we will get a similar functionality for 2-3 algorithms in total, before that it looks a bit premature. It should be possible to add...

For v0.8 it will have to be feature-gated behind some feature (it can be the same `simd` feature), but I am thinking about migrating to Rust 2018 for v0.9.

Is there a risk of more complex corruptions other than empty image?