Tony Arcieri

@juliankrieger perhaps sketch out what you have in mind here, and then open a PR which implements it

@ClearlyClaire @misalcedo we're looking at shipping v6.0.0 in #790. It's the last chance to make breaking changes to the timeout subsystem. Would either of you like to open a PR,...

> I think it needlessly will expose implementation detail in the form of SIMD types Without SIMD types that can be used between crates, we wind up round tripping data...

> Can't the same approach be applied tol `ParBlocks`? It also can be a generic parameter instead of associated type. Yes, but only if there were a separate trait for...

I opened https://github.com/RustCrypto/utils/pull/221 which contains a WIP prototype of a `simd-buffers` crate.

I'm reopening this as we continue to get complaints about performance, and attempting to implement one-pass operation for either AES-GCM or ChaCha20Poly1305 does not yield the expected speedups: - https://github.com/RustCrypto/AEADs/issues/243#issuecomment-1560478160...

Would definitely be good to get #619 out first This should probably also bump the versions of `curve25519-dalek`/`ed25519-dalek` to e.g. 4.2.0-pre/2.2.0-pre respectively per the exemptions to our SemVer policy, to...

I believe when it was originally added the concerns were things like interruption by signal handlers, though now I can't find the previous discussion

`asm!` is only supported on a limited number of platforms, so we still need a portable fallback. BTW this is more or less what was proposed in #841.

> We probably then should use the asm! black box on supported targets and use core::hint::black_box as a best-effort fallback on others. The documentation for `core::hint::black_box` is pretty adamant that...