You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
I'm not sold that it's useful, though it would I guess be doable. We should at least warn if a non-conditionally-const item exists in a impl with ~const.
Decide once and for all if we want to support
~const
bounds in inherent impl headers: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: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.
The text was updated successfully, but these errors were encountered: