Error CS0695 is not considering constraints

[acaly]

interface IObject {}

class TheObject : IObject {}

interface IObjectList : IEnumerable<IObject> {}

//This raises the error CS0695, even if TObject cannot be IObject
class TheObjectList<TObject> : IObjectList, IEnumerable<TObject> where TObject : TheObject
{
  //implementation of interface methods
}

I think this is because the check for conflicts ignores any constraints (I am not sure whether it's also related to CLR), but having IEnumerable, for example, for multiple types is sometimes useful because it saves a conversion step. I wonder whether this could possibly be improved in the future. Thanks!

[TheUnlocked]

I don't see how the constraint stops TObject from being an IObject. TheObject is an IObject, so TObject will always be an IObject.

[acaly]

TObject always implements TheObject, which is a class, so it cannot be the interface IObject.

Reminder: you can implement IEnumerable<IObject> and IEnumerable<TheObject> without any problem.

[canton7]

For those who haven't memorised all of the CSXXXX codes:

error CS0695: 'TheObjectList<TObject>' cannot implement both 'IEnumerable<IObject>' and 'IEnumerable<TObject>' because they may unify for some type parameter substitutions

[khm1600]

the spec:

To determine if the interface list of a generic type declaration is valid, the following steps are performed:

• Let L be the list of interfaces directly specified in a generic class, struct, or interface declaration C.
• Add to L any base interfaces of the interfaces already in L.
• Remove any duplicates from L.
• If any possible constructed type created from C would, after type arguments are substituted into L, cause two interfaces in L to be identical, then the declaration of C is invalid. Constraint declarations are not considered when determining all possible constructed types.

[acaly]

Yes I understand this is in the spec. That's why I am asking in the language design repo...

Actually the compiler is already doing some hard work in deciding whether

any possible constructed type created from C would, after type arguments are substituted into L, cause two interfaces in L to be identical

For example, the following declaration is valid

    interface I1<T1, T2, T3> { }
    interface I2<T1> { }
    class C<T1, T2> : I1<int, uint, T1>, I1<T1, T2, T2> { }

while this is not

    interface I1<T1, T2, T3> { }
    interface I2<T1> { }
    class C<T1, T2> : I1<int, uint, T1>, I1<T1, T2, T1> { } //the last one changed to T1

To check this, I imagine that the compiler needs to go layer-by-layer into the generic arguments and get a list of types for each generic parameter and check whether those types can be identical. For the first example here, it would give T1={int, T2} and T2={uint, T1}. Because int != uint, it's impossible for the two interface to be identical. For the second, T1={int}, T2={uint}, which is possible.

If we look at the example I wrote in the question, it would give TObject={IObject}. It also has the constraint TObject : TheObject. It should be able to see that IObject cannot satisfy TheObject constraint. I know little about the internal of the compiler so I am curious whether adding the constraint check for these lists would significantly complicate it.