Unclear interaction between const generics and coherence checking

[Aaron1011]

Consider the following code:

trait Foo {
    const VAL: usize;
}

trait MyTrait {}

trait True {}
struct Is<const T: bool>;
impl True for Is<{true}> {}

impl<T: Foo> MyTrait for T where Is<{T::VAL == 5}>: True {}
impl<T: Foo> MyTrait for T where Is<{T::VAL == 6}>: True {}

Coherence checking needs to determine whether the two MyTrait impls can ever overlap. This requires determining (among other things) if {T::VAL == 5} and {T::VAL == 6} will ever have the same value - if they do, then the impls will overlap.

In this case, we can see that T::VAL == 5 and T::VAL == 6 can never both be true. However, in the general case, we could have an expression like Is<{someConstFn(T::VAl)}. Coherence checking would need to determine if two const functions will ever produce the same value for a given input. This seems impossible without radically extending the Rust language and/or the abilities of the compiler.

One solution would be to ban any const projections within where clauses. That is, where Is<{2 + 2 == 5}>: True would be allowed, but where Is<{T::VAL == T::VAL}>: True would not be. This would ensure that it's always possible to fully const-eval an expression during coherence checking, which allows us to be certain about whether or not two impls overlap.

[Aaron1011]

I think we actually need to ban all generic parameters from const expressions in trait impl where clauses.

Consider this code:

impl<T> MyTrait for T where SomeStruct<{type_name::<T>()}>: True

This would require coherence checking to determine if any other impls have a const equal to the name of the type the trait is implelented on - or in general, any const fn of the name.

While this introduces an unfortunate inconsistency in const generics (these kinds of where clauses are perfectly fine on functions), I don't sees any way around it.

[Aaron1011]

Actually, there is one alternative: for the purposes of coherence checking, deliberately over approximate the cases where this kind of impl can apply.

That is, we would treat an impl like

impl<T> MyTrait for T where SomeStruct<{type_name::<T>()}>: True

as though the user had written

impl<T> MyTrait for T {}

That is, we treat the where clause as always applying, which means that this impl would be considered to conflict with any other impl of MyTrait.

The impl would not actually apply for all T - attempting to use it in any other code will cause the full impl to be used.

I believe this would be sufficient to ensure that coherence never needs to 'invert' arbitrary const expressions.

[varkor]

It would be sensible for now to forbid arbitrary const expressions in where clauses, and just allow generic parameters. We could extend this later once we've figured out all the subtleties.

[varkor]

Note to self: the example in the first post is a good test candidate for using the correct ParamEnv, as it currently fails.

[Aaron1011]

It would be sensible for now to forbid arbitrary const expressions in where clauses.

It turns out that libcore is currently doing this - it's generating impls of the form impl<T> Default for [T; 32], impl<T> Default for [T; {32 - 1}], etc. We could add some kind of opt-out for libcore, but that seems like it could be more trouble than it's worth.

I think it would make sense to ban anything other than a plain const parameter (e.g. MyStruct<{P}>) or const expressions that don't involve any generics whatsover (e.g. MyStruct<{myConstFn(1 + 2) * 3)}>). In the future, we could consider allowing some expressions involving const paramters, once we decide on how that will interact with coherence checking.

[lcnr]

I feel like this issue is somewhat outdated and would go ahead and close this.

@Aaron1011 is there something we should do here?

[lcnr]

Looking at the original example:

trait Foo {
    const VAL: usize;
}

trait MyTrait {}

trait True {}
struct Is<const T: bool>;
impl True for Is<{true}> {}

impl<T: Foo> MyTrait for T where Is<{T::VAL == 5}>: True {}
impl<T: Foo> MyTrait for T where Is<{T::VAL == 6}>: True {}

From what I know we do not reason about generic consts, so T::VAL == 5 and T::VAL == 6 will remain opaque during coherence checking (causing this example to fail). I will go ahead and mark this as E-needs-test so we don't accidentally allow this in the future and then close this.

I do not think reasoning about generic consts is something we want to do in the near future.