Const generics unconstrained generics

[DutchGhost]

The following code does NOT compile:

#![feature(const_generics)]

struct Collatz<const N: Option<usize>>;

impl <const N: usize> Collatz<{Some(N)}> {
    
}

fn main() {
}

it errors with:

error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates
 --> src/main.rs:5:13
  |
5 | impl <const N: usize> Collatz<{Some(N)}> {
  |             ^ unconstrained const parameter

However, when using normal generics in the places of the const generics, wrapping the T in an Option and sticking that into the Collatz struct does work:

struct Collatz<T>([T; 0]);

impl <T> Collatz<Option<T>> {}

Is it intended that const generic dont mimmic this behaviour?

[varkor]

Is it intended that const generic dont mimmic this behaviour?

This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form Foo<N> at the moment (cc ##60471).

[lcnr]

Considering that anon consts are mostly just projections, wouldn't this be similar to

#![feature(const_generics)]

struct Collatz<T>(T);

trait Foo {
    type Assoc;
}

impl<T: Foo> Collatz<T::Assoc> {}

fn main() {}

which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of T to a unique type).

While Some(N) is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn.

Not quite sure what's the best error message though 🤔

probably something like

error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates
 --> src/main.rs:5:13
  |
5 | impl <const N: usize> Collatz<{Some(N)}> {
  |             ^ unconstrained const parameter
note: const parameters can be constrained by using them in a trivial expression

[varkor]

That's a good point @lcnr. I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).