Consider redefining the places ~const bounds are allowed

[fee1-dead]

At #102409 (comment), it was pointed out that associated functions can have ~const bounds even though they may be non-const. We need to figure out and define what places ~const should be allowed. Note that since ~const only applies more restrictions on callers that are const, putting them on non-const fns has no effect.

[oli-obk]

Why can't we just forbid it on non const assoc fns?

[fee1-dead]

Yes we can. I was also thinking about impl<T: ~const Tr> SomeType {} so that all const fns inherit this bound.

[oli-obk]

Ah yea, seems ok as long as we have an unused ~const lint for the case where nothing uses it

[onestacked]

Yes we can. I was also thinking about impl<T: ~const Tr> SomeType {} so that all const fns inherit this bound.

I think that would make a lot of const code a bit cleaner.

[oli-obk]

I tried implementing this with effects, but it's a bit messy. Right now, we desugar

impl SomeType {
    const fn foo<T: ~const Trait>() {}
}

to

impl SomeType {
    fn foo<effect C: constness, T: Trait<C>>() {}
}

but in order to allow

impl<T: ~const Tr> SomeType {
    const fn foo() {}
}

to use the <T as ~const Tr> information, we'd need an effect available on the impl level, so

impl<effect C: constness, T: Tr<C>> SomeType {
    const fn foo() {}
    fn bar() {}
}

but then non-const fns like bar now suddenly have const effects in their generics. This all seems resolvable, but I'm going to mark the existing test as // known-bug pointing to this issue and look into this again once the rest works reliably

[fee1-dead]

Can we ignore the constness effect in non-const contexts?

[oli-obk]

Can we ignore the constness effect in non-const contexts?

The current design treats the presence of a constness effect as the source of truth for whether a function is const fn. I tried going back to the existing constness/is_const_fn_raw checks, but that turned out to cause lots of problems in other situations so I stopped pursuing this for now.