Tony Arcieri

Yes, unfortunately we're doing a big `rand_core` v0.10 update and while the git repo is updated, we can't cut a release until we land this PR: - https://github.com/zkcrypto/group/pull/69 Which is...

There are similar issues with lazy reductions in crates like `k256` and `p521`. Perhaps support for lazy reductions should be added to `ff`, e.g. with a separate type to represent...

> While I won't say it's impossible to leverage the Rust type system to check at compile-time the amount of correct operations remain, I believe the effort entirely outstrips the...

I remain curious about whether we could put together traits to be upstreamed to `ff` which could capture lazy reduction and avoid the need to introduce an intermediate wrapper type....

I was thinking more like: try to create a zero-cost abstraction which avoids the need to have a suboptimal wrapper type to fit an API it diverges from. And if...

Maybe just call it `hazmat`? I know `expose-field` matches e.g. `k256` but I've considered renaming that. Perhaps it should also be placed under a `hazmat` module. @kayabaNerve the only build...

Okay, apologies, I work on too many elliptic curve crates and forgot that `curve25519-dalek` doesn't actually expose a `FieldElement` type yet. Will have to think about that one. Ideally I...

An API like this sounds fine to me. I'd probably call it something like `from_affine_coordinates`. `AffinePoint::from_coordinates` would probably also work if we exposed it. We support similar functionality in the...

Oh wow, so it is! Wonder when that happened

Semi-related: https://github.com/RustCrypto/traits/issues/1994