Yes. I have been holding on updating the pre-RFC until things settle a bit (will probably submit the modified version as a reply here).
To explain my position with examples, I am a bit torn about the following two ways to proceed:
- scaling it down to what @kennytm proposes
- layering this as "type-inference" for
const
parameters on top of RFC2000
First, independently of what we choose here, this "feature" requires RFC2000 to be implemented, so this must necessarily come after const
-generics. That is, by the time this lands, we will already have const
generics. AFAIK there is no way around this.
At that point, adding type inference for consts like this:
// before:
fn foo<const N: usize>() { }
foo::<3>(); // OK
// RFC on top of const generics:
fn foo<const N: usize>(n: N) { }
foo::<3>(3); // STILL OK
foo(3); // NOW ALSO OK
seems like a natural extension that is consistent to how we already treat type-parameters. @kennytm is concerned about the following example
let a = foo(3); // a: [i32; 3]
let b = foo(4); // b: [i32; 4]
However, I think this situation is analogous to:
fn foo<T>(x: [T; 3]) -> [T; 3] { x }
let a = foo(3); // a: [i32; 3]
let b = foo(3); // b: [usize; 3]
// ...
let (x: [i32; _], y: [usize; _]) = (a, b);
and in general many similar situations that can happen with type-inference today. If anything, I think that this way of going forward would at least be consistent, which means that users won't need to learn new ways of thinking to figure out how type-inference works.
OTOH if we were to allow this:
fn foo(const N: usize) { }
It is unclear to me if it would be worth it to make this play with const
-parameters (<const N: usize>
), and if so, how that interaction would look like. The ones we have discussed here all have drawbacks when trying to scale them up to just sugar over full const
-generics:
fn foo(const N: usize) {}
fn foo<const N: usize>(const N: usize) {}
fn foo(N: const usize) {}
fn foo<const N: usize>(N: const usize) {}
This is not a problem if we never intend to scale them up, but the "unknown" makes me a bit uncomfortable.
Because of this, I tend to favor the "adding type-inference for const
-parameters" route. But of course, for that to happen, we would need to settle the type/kind/value related issues. I'd prefer to settle those first, because we need to settle them anyways for const
-generics even if we never move forward with this pre-RFC. After those are settled, revisiting this might be easier, and the path forward much more clearer.