Use const generics where feasible

[tgeoghegan]

Once const generics (1 2) are out of beta, we might consider them to implement FieldElement as a generic over values of FieldParameter.

[tgeoghegan]

It turns out I misunderstood this post: const generics are stable and generally available in Rust 1.51, so we could investigate adopting this now.

[cjpatton]

I think we should keep FieldElement as a trait, as it would be useful to have around in case someone comes along with an alternative implementation of a particular field. What we could do is replace the make_field!() macro with an implementation of FieldElement that uses a const generic FieldParameter. Call it GenericField.Then we would implement the concrete fields as

type Field32 = GenericField<FP32>;
type Field64 = GenericField<FP64>;
type Field80 = GenericField<FP80>;
type Field126 = GenericField<FP126>;

[cjpatton]

Const generics supports only primitive types, like integers. As such, we can't use them for FieldElement in this way.

An area where const generics would be very helpful is in the gadget implementations (prio::pcp::gadgets). In particular, the PolyEval<F> struct has a Vec<F> as a parameter:

pub struct PolyEval<F: FieldElement> {
     poly: Vec<F>,
     /// Size of buffer for FFT operations.
     n: usize,
     /// Inverse of `n` in `F`.
     n_inv: F,
}    

Usually poly.len() will be known at compile time, so we could write this as

pub struct PolyEval<F: FieldElement, const L: usize> {
     poly: [F; L],
     /// Size of buffer for FFT operations.
     n: usize,
     /// Inverse of `n` in `F`.
     n_inv: F,
}    

[tgeoghegan]

We've tried a couple times now to use const generics in this library (#85) and it hasn't worked out. @cjpatton and I agree we can't be taken seriously as a Rust cryptography project until we manage to use this language feature, so we will figure out a way to to adopt it! One promising candidate would be to make vdaf::dist_input and vdaf::dist_init (or whatever they get renamed to) return constant sized arrays.

[cjpatton]

One promising candidate would be to make vdaf::dist_input and vdaf::dist_init (or whatever they get renamed to) return constant sized arrays.

I'm now less certain that this is a good idea. The downside, of course, is the number of shares needs to be known at compile time. If there is no obvious benefit other than aesthetics, then I don't think it's worth doing.

My main takeaway from this side quest so far is that const generics aren't mature enough to use the way we imagine they're intended to be used.

[cjpatton]

We now use const L: usize for the side of PRG seeds.

[tgeoghegan]

As const generics continue to evolve in the language, we'll keep trying to use them as appropriate, but this issue doesn't track any specific work or problem so I'm closing it.