generic_const_exprs and inline_const interact poorly.

[emilio]

On current nightly, this code works:

#![feature(inline_const)]

fn foo<const N: usize>() {
    const {
        assert!(N > 0);
    }
}

fn main() {
    foo::<4>();
}

However this code fails to compile if generic_const_exprs is enabled, by just adding #![feature(generic_const_exprs)] at the top of the file:

error: overly complex generic constant
 --> t.rs:5:11
  |
5 |       const {
  |  ___________^
6 | |         assert!(N > 0);
7 | |     }
  | |_____^ blocks are not supported in generic constants
  |
  = help: consider moving this anonymous constant into a `const` function
  = note: this operation may be supported in the future

error: aborting due to 1 previous error; 1 warning emitted

Which is clearly broken? generic_const_exprs should probably not try to dig into that expression to begin with.

[fmease]

Right, this is a very interesting case. Ignoring the fact that inline consts are considered too complex for generic const exprs (just a limitation of the current implementation I'd wager), inline consts and generic const exprs are fundamentally at odds conceptually:

Feature GCEs is all about checking and guaranteeing that const exprs are well-formed for all generic parameters in scope (ad-hoc polymorphism, ensuring parametricity to a certain degree, pre monomorphization checks), while ICs are currently evaluated post monomorphization. There have been lots of discussions over at the stabilization PR of ICs iirc and I don't know what T-lang's current stance is.

[RalfJung]

Note that inline consts behave exactly like associated consts, so if there is some conflict between GCE and inline const then it should also arise with associated consts.

There have been lots of discussions over at the stabilization PR of ICs iirc and I don't know what T-lang's current stance is.

Given that inline_const are stable on nightly and riding the train, I think it is safe to say that having the error during monomorphization is accepted by T-lang.