Lessen Generic Type Parameter Substitution Restriction when Implementing same Interface for different Ts

[fitdev]

Considering code like:

/* <- CS0695: 'Foo<T>' cannot implement both 'IBar<T>' and 'IBar<bool>' because they may unify for some type parameter substitutions */
public readonly struct Foo<T>  : IBar<T>, IBar<bool> where T : class {

}
public interface IBar<T> {
  void Do(T item);
}

It seems that CS0695 is too restrictive: T is constrained to class therefore it can never be bool, and therefore bool and T may never in fact unify. Hence it should be allowed for a type to implement both generic versions of the same interface for different Ts.

Ideally this restriction should be lessened even more to cover various reference type hierarchies where it can be shown that again Ts won;t unify (due to having different inheritance hierarchies).

[huoyaoyuan]

The check done in CLR doesn't seem to take generic constraint into account:

https://github.com/dotnet/runtime/blob/22183356ccdedbe4cbc0394e162bda8fbf163b1f/src/coreclr/vm/methodtablebuilder.cpp#L9428-L9448

However, there's other comment hinting that some check can be delayed at instantiation time:

https://github.com/dotnet/runtime/blob/22183356ccdedbe4cbc0394e162bda8fbf163b1f/src/coreclr/vm/methodtablebuilder.cpp#L9515-L9520

---

Despite that, multiple implementation of generic interface is already distorted. Consider this example:

var c = new C();

Console.WriteLine((c as I<Base>).Dispatch());

class C : I<Derived1>, I<Derived2>
{
    string I<Derived1>.Dispatch() => "Dispatched with Derived1";
    string I<Derived2>.Dispatch() => "Dispatched with Derived2";
}

class Base { }
class Derived1 : Base { }
class Derived2 : Base { }

interface I<out T>
{
    string Dispatch();
}

The covariant dispatch result will depend on the declaration order of interface implementation.

I don't think it's encouraged to support more corner cases for this.

[jaredpar]

I would say that this would need to start with convincing the runtime to fully support this. Even then ... not entirely sure we'd want to take this on in the language. It's hard to see the scenarios justifying the effort.