allow const generics in const fn

[lcnr]

This was explicitly forbidden before. As we were unable to think of a reason
why this should still be the case, this check has been removed.

r? @eddyb
cc @varkor @Centril

[eddyb]

@bors r+

[bors]

📌 Commit 50eb397 has been approved by eddyb

[varkor]

@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]

We could certainly move it elsewhere, but there are definitely still concerns with its interactions with const fn. At any rate, I don't see that there's any urgent need to combine the two features at present anyway.

[eddyb]

@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;
}

[varkor]

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.

[varkor]

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

[varkor]

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

[bors]

📌 Commit 50eb397 has been approved by eddyb