On-demand const verification may be a backwards compatibility hazard

[huonw]

E.g. #19244 describes how the following is valid, but uncommenting the line causes the error given below.

struct Wrapper(usize);
const BAD_CONST: usize = Wrapper(42).0;

// type X = [u8; BAD_CONST];

fn main() {}

3 | const BAD_CONST: usize = Wrapper(42).0;
  |                          ^^^^^^^^^^^ unimplemented constant expression: tuple struct constructors

(NB. that specific instance may be fixed in future, but that does not necessarily mean this bug is fixed.)

That is, the const-suitability of the value is checked when used as a constant expression, not at the definition. This could possibly may lead to surprises if rules are tweaked (at least, it could lead to surprises that are not detected). In any case, it is certainly confusing for a const to apparently be an unsupported constant expression.

It seems that we could check the definitions, not just checking them lazily when they are used as const expressions.

[brson]

P-low, not 1.0

[nikomatsakis]

I am not sure how bad this is. There are constants that we cannot evaluate at type-checking time but only at trans time. Eventually I think we can (and should) make that distinction very small or even non-existant, but I don't think it means that those constants can't exist in the first place (which seems to be what @huonw is suggesting).

[oli-obk]

Related issue: #3170 (comment)

const ARR: [u32; 0] = []; const X: u32 = ARR[5];

The above doesn't error until you do let x = X; somewhere.