Explicitly specify generic numerical parameters

[nventuro]

Problem

I want to write functions that are generic over some parameter N, where N is not a type but a numeric value. This is currently supported only if N is used as an array length in a struct definition or function parameter.

Happy Case

With structs

The following code fails to compile with N is not in scope. While perhaps convoluted, it is a real example of a pattern I'm working on in Aztec-nr:

struct MyStruct<N> {
  a: Field,
}

impl<N> MyStruct<N> {
  fn foo(self) -> Field {
    self.a + N
  }
}

This can be currently worked around by adding a dummy array, as suggested by @jfecher:

struct MyStruct<N> {
  a: Field,
  _dummy: [Field, N],
}

This workaround seems good enough for use cases in which the struct has other data, as the only side effect is slightly wonky construction.

Without structs

If the impl functions don't receive self, then the workaround presented above does not work. This prevents implementing patterns of the form range().map().reduce i.e. doing something a number of times, collecting that into an array and then using that array to produce a value. An example of this is public storage reads:

trait Deserialize<N> {
    fn deserialize(fields: [Field; N]) -> Self;
}

#[oracle(storageRead)]
fn storage_read() -> Field {}

struct PublicStorage {}

impl PublicStorage {
    fn read<T, N>() -> T where T: Deserialize<N> {
        let mut fields = [0; N];
        for i in 0..N {
            fields[i] = storage_read();
        }
        T::deserialize(fields)
    }
}

The above does not compile with N is not in scope for the 0..N part. I could not find a way to make it work, except by making N a type parameter for PublicStorage, adding the dummy variable and making read take self (which I'd rather avoid).

This has not been an issue so far because we read storage in an array, but with AztecProtocol/aztec-packages#5153 this is going to change, and it is already like that for historical public storage reads in private, which are done one at a time.

Project Impact

Blocker

[TomAFrench]

Solution to this would end up being some form of const generics system.

[jfecher]

Solution to this would end up being some form of const generics system.

We already have const generics, we just call them numeric generics. The thing we're lacking here is just a better way to tell the compiler "this type variable must be numeric, you can safely introduce it into the expression scope." Rust does this via fn foo<const N: usize>() I think we can do fn foo<N: usize>() if we wanted - not sure why Rust didn't leave out the const as well. It may be because now it shares the same syntax as a trait constraint. If we want to avoid this as well, we can't 100% follow rust here since we don't have a const keyword. If we want to avoid introducing a const keyword for this then perhaps let works best of the keywords we have right now: fn foo<let N: usize>.

[TomAFrench]

Yeah "system" -> "syntax" is closer to what I was thinking. Apologies for not being clear.