@bors r+

📌 Commit 50eb397 has been approved by eddyb

@bors r-

This was a deliberate decision. The interactions with const fn and const generics are unclear, as it can lead to a form of dependent typing that we need to carefully examine before permitting. In addition, the const generics RFC did not permit const generics to be specified on const fn.

@varkor I've never heard of this and it doesn't make sense to me.
A link to prior discussion would be helpful.

You can already do everything const fn with generic parameters can, using this construction:

struct Foo<const X: u32, const Y: u32>;
impl<const X: u32, const Y: u32> Foo<X, Y> {
    const OUTPUT: u32 = X + Y;
}

This was discussed on Discord during implementation; I may be able to find a link if Discord has recorded this much history. I need to think about the example, as I haven't thought about this in a long time.

(We're discussing this on Zulip. If it's a false alarm, I'll re-approve shortly.)

After discussing this, we agreed that allowing this case should not be a concern: I was worrying about calling const fn inside const arguments and the implications for const unification, but this is a separate concern that we should be able to deal with when we consider more advanced forms of unification than identity-checking. Here is a link to the relevant discussion on Zulip.

@bors r=eddyb

📌 Commit 50eb397 has been approved by eddyb