Lift signal bit widths into type system when Rust achieves proper support for const generics

[yupferris]

This has basically always been the plan, but is on hold until everything is stable. This will be very much a breaking change but I can imagine a lot of user code actually won't look much different due to type inference.

It looks like this is the tracking issue min_const_generics, which is the minimal feature subset that will be stabilized first, but it's not quite sufficient.

[yupferris]

I believe this will also be required for this use case in order to be able to calculate bit widths for combined Signals - eg. a * b will produce a new Signal whose bit width is the sum of the bit widths of a and b respectively. This means the signature of mul will be something like fn mul<const N: u32, const M: u32>(a: &Signal<N>, b: &Signal<M>) -> Signal<N + M> which is not supported with only min_const_generics.

Note also that it's possible for N + M to exceed the maximum bit width supported by a particular kaze version, which also needs to be checked/reported at compile time. I haven't dug deeply enough to know which feature(s) are required/available in order to implement this.

[kaoet]

Is it possible to use https://docs.rs/typenum instead before the stablization of generic_const_exprs?

[yupferris]

Is it possible to use https://docs.rs/typenum instead before the stablization of generic_const_exprs?

Very interesting, it looks like this may have what we need. I’ll do some evaluation work and see if it meets our needs and if the resulting type errors are overwhelming or not.