Afaik we do not have &G2Prepared: Into<G2Prepared> sensibly, so every invocation requires duplicating the G2Prepared, like 16kb or more.
fn multi_miller_loop(
a: impl IntoIterator<Item = impl Into<Self::G1Prepared>>,
b: impl IntoIterator<Item = impl Into<Self::G2Prepared>>,
) -> MillerLoopOutput<Self>;
You'll notice zcash abandoned the generics in the equally messy old interface. You'd still avoid the preparation time by cloning the G2Prepareds, but we never modify G2Prepared so idiomatic rust would allow borrows here.
Could we borrow but retain the Into somehow? I suspect maybe..
fn multi_miller_loop(
a: impl IntoIterator<Item = impl Into<impl Borrow<Self::G1Prepared>>>,
b: impl IntoIterator<Item = impl Into<impl Borrow<Self::G2Prepared>>>,
) -> MillerLoopOutput<Self>;
It's possible rustc winds up confused by the multiple trait layers here, under some uses, not sure.
As an aside, rustc won't let associated types remove the impl Borrow flexibility and Into<Cow<..>> breaks oddly. It's also plausible rust-lang/rfcs#3382 helps somehow. I'm most hopeful for the above however.
Afaik we do not have
&G2Prepared: Into<G2Prepared>sensibly, so every invocation requires duplicating theG2Prepared, like 16kb or more.You'll notice zcash abandoned the generics in the equally messy old interface. You'd still avoid the preparation time by cloning the
G2Prepareds, but we never modify G2Prepared so idiomatic rust would allow borrows here.Could we borrow but retain the
Intosomehow? I suspect maybe..It's possible rustc winds up confused by the multiple trait layers here, under some uses, not sure.
As an aside, rustc won't let associated types remove the
impl Borrowflexibility andInto<Cow<..>>breaks oddly. It's also plausible rust-lang/rfcs#3382 helps somehow. I'm most hopeful for the above however.