erasable `const`-ness on types and `TypeId`

[lcnr]

I have personally wanted for const fn(u32) and fn(u32) to be the same types at codegen once/if we ever add them. This requires const-ness of types to not influence selection.

It also requires TypeId::of::<const fn(u32)>() to error, as you can otherwise cast from fn(u32) to const fn(u32) which would be broken. Doing this would likely require a new bound on TypeId which only works by introducing a new default trait bound. Doing so is very questionable and means we're pretty much forced to treat them as different types.

by @BoxyUwU:

because then you could call a runtime only fn at compile time and thats (?)
well I mean we could error on it when you actually do it [during CTFE] but that feels like we failed in the type system xd

[programmerjake]

I want to treat const fn() as a different type anyway, because it lets you distinguish between f and g's generic's types:

fn f<const F: const fn(u8) -> u8>() -> ([u8; F(1)], [u8; F(2)]) {
    todo!()
}

fn g<const F: fn(u8) -> u8>() -> [u8; 2] {
    [F(0), F(1)]
}

[lcnr]

I have personally wanted for const fn(u32) and fn(u32) to be the same types at codegen once/if we ever add them.

as in: I want their TypeId to be the same and whether something is a const-fn to never impact trait selection. I would very much expect these to be different types during analysis, and e.g. prevent assigning an fn() to a const fn(). The same way fn(&'static u32) and fn(&'not_higher_ranked u32) are different types but are treated as equal outside of analysis.