evaluatable bounds are fun uwu

We cannot ignore CTFE failures of constants used in the type system

An impl like this is considered exhaustive

impl<const N: usize> Trait<N> for () {
    type Assoc = [u8; 32];
    const ASSOC: usize = N;
}

If we were to ignore (): Trait<error>, what are sensible values for the associated items of that type.

pretty clear stuff

  • Without evaluatable bounds, errors during monomorphization are unavoidable
  • reaching the evaluation limit HAS to be a hard error and cannot be guarded against
    • same for recursion and size limits

why are constants used in the type system special

Constants used in expressions could simply panic on use. Constants used in the type system cannot be ignored when detected.

questions, thoughts, other stuff

  • is there a difference between constants used in the type system and constants simply used in expressions?
    • generic constants in expressions are already allowed without evaluatable bounds
      • and instead with post mon oerrors which is dumb it should be a runtime panic
        • is it, why?
          • "soundness" if its an abort it will be fine
          • or could just be done over an edition I guess..? idk
          • also, people rely on that behavior for soundness, so changing it seems hard
          • the why is because it means you cant ensure something is eavluated at compile time as an optimization without opting into a post mono error for code that might not actually even get run
      • I actually wrote why that is fine
        • gdi we should have writtin all of this down somewhere xd
  • just make it a lint, why hard error?
    • people are stupid and silence lints they don't understand

previous discussions

associated consts wf https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/associated.20consts.20const.20wf

which builds on https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const.20wf.20bounds.20implementation