Continuation of a discussion at #276: the second phase challenges can only use FnOnce + 'static since #276.
This effectively breaks the API (and apparently, rightfully, annoys @oleganza)! We have to pass a generic lifetime to the RandomizableConstraintSystem trait in order to constrain the lifetime to the container in Prover and Verifier. I don't think there's another way, except maybe with GATs (which would bring different API breaks anyhow).
How about upgrading from Fn to FnOnce in this PR, but keeping the 'static requirement, and then separately explore if moving to generic lifetime bound is worth it? Right now i have to propagate 'a in a ton of places in ZkVM, because where I had a vm::Verifier, now I have vm::Verifier<'a>, and it leaks to PrecomputedTx that wraps it, etc. I could probably slap 'static at some point inside ZkVM/Spacesuit, but that would push the burden of justification on my codebase and I'm just... ugh... not ready for it right now :-P
Maybe this needs an additional interesting test-case for multiple different lifetimes and borrows?
Not specifying an explicit lifetime on &mut self might get people into trouble with late-bound lifetimes. I've had that while experimenting on it, but haven't come to fix it yet. I think it should be possible to add it later though, without breaking API...
Depends on #244/#276 (I'll rebase on develop when #276 is merged, too much conflicts to handle otherwise)
Continuation of a discussion at #276: the second phase challenges can only use
FnOnce + 'staticsince #276.This effectively breaks the API (and apparently, rightfully, annoys @oleganza)! We have to pass a generic lifetime to the
RandomizableConstraintSystemtrait in order to constrain the lifetime to the container inProverandVerifier. I don't think there's another way, except maybe with GATs (which would bring different API breaks anyhow).&mut selfmight get people into trouble with late-bound lifetimes. I've had that while experimenting on it, but haven't come to fix it yet. I think it should be possible to add it later though, without breaking API...Depends on #244/#276 (I'll rebase on develop when #276 is merged, too much conflicts to handle otherwise)