Suggested resolution to "unconstrained generic constant" does not make sense for types other than usize

[nickmertin]

Based on a StackOverflow question.

Given the following code: (Playground)

#![feature(const_generics)]
#![feature(const_evaluatable_checked)]

use std::ops::Mul;

pub struct Foo <const bar: i64> {
    value: f64,
}

impl<const baz: i64, const quux: i64> Mul<Foo<quux>> for Foo<baz> {
    type Output = Foo<{baz + quux}>;

    fn mul(self, rhs: Foo<quux>) -> Self::Output {
        Self::Output {
            value: self.value * rhs.value,
        }
    }
}

fn main() {
    let a: Foo<3> = Foo { value: 2.0 };
    let b: Foo<4> = Foo { value: 9.0 };
    let c = a * b;
    println!("{}", c.value);
}

The current output is:

error: unconstrained generic constant
  --> src/main.rs:11:5
   |
11 |     type Output = Foo<{baz + quux}>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
help: try adding a `where` bound using this expression: `where [u8; {baz + quux}]: Sized`

This suggestion fails to compile, because baz and quux (and their sum) have type i64, while the context of a slice length requires usize. Ideally, it should instead suggest where Foo<{baz + quux}>: Sized, which does compile.

Strictly speaking, pulling out the context of the constant expression's use and checking if it implements Sized will not work if the type is not supposed to implement Sized; perhaps PhantomData<Foo<{baz + quux}>>: Sized would be an alternative to suggest in that case. Overall, the pattern does seem a little hacky, working around the fact that there is no way to specify a constraint that a type exists.

[lcnr]

For now the solution is to have a custom type with a const parameter of the right type

struct Evaluatable<const N: i32>;

... where Evaluatable<{ my_expr }>: Sized

if these bound ever get required on stable, we will improve the error message and add a nicer way to add these bounds. Until then we're sadly stuck with this horrible hack xx