Decide once and for all if we want to support ~const bounds in inherent impl headers:

//@ check-fail
//@ compile-flags: -Znext-solver
#![feature(const_trait_impl, effects)]
#![crate_type = "lib"]

#[const_trait] trait Bound { fn f(); }
struct Ty<T>(T);     

impl<T: ~const Bound> Ty<T> {
//      ^^^^^^^^^^^^
    const fn g() { T::f() }
}

Indeed back when we had the earliest const host: bool desugaring, we decided to reject them and to this day we reject them during AST validation. See rust-lang/rust#117817 (comment) and rust-lang/rust#119059. We currently require the user to move the ~const bound from the impl header to the associated function:

//@ check-pass

// ...

impl<T> Ty<T> {
    const fn g() where T: ~const Bound { T::f() }
//                        ^^^^^^^^^^^^
}

I think the biggest reason was the fact that you couldn't represent this in the old desugaring because you couldn't really couple the host effect param for Bound with the one of <T> Ty::<T>::g. Indeed, it's a bit backwards.

It might be worthwhile to revisit this decision now that we have a different representation. I could be far off base here, though. Feel free to correct me.