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.
Decide once and for all if we want to support
~constbounds in inherent impl headers:Indeed back when we had the earliest
const host: booldesugaring, 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~constbound from the impl header to the associated function: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
Boundwith 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.