Allow to implement same generic interface for more that one type parameter in generic class under some conditions by TAG

I agree with mark n and TAG. With the current behaviour, you can't even implement a class that accepts a stream of two values T0 and T1 by implementing class Foo<T0, T1> : IObvservable<T0>, IObservable<T1> because T0 and T1 may unify. Whether T0 and T1 unify is *irrelevant* to whether this is well-typed.

Certainly there are *some* cases where unification is nonsensical, but there are plenty where it makes perfect sense. I can provide numerous examples.

I've changed my mind....there (should be) absolutely nothing wrong with unification, and implementing the same interface twice is logically valid, and should be allowed in general. As long as the object satisfies it's contract it is (functionally) irrelevant which implementation is actually used to do so, this is really the basic tenet of OO programming, so if the interfaces unify then the compiler is at liberty to choose whichever implementation it wishes....it would seem sensible to have a hard and fast rule, e.g. it chooses the first one.

I have a similar problem....

interface IA<T1> {}

interface I2A<T1,T2> : IA<T1>,IA<T2>
{
}

I'm not sure whether I believe (probably because I do not completely understand).....the reasoning in the comment about it being
a) complexity of algorithm
b) a type implementing another interface in the future.

I would suggest the solution of;
a) allowing the construct, and checking for the unification in the type instantiation, rather than the declaration (if you see what I mean)
b) creating a new 'where' clause of 'not'...though this may be an interesting can of worms....but

interface I2A<T1,T2> : IA<T1>,IA<T2> where T1 !: T2
{
}

Hi Tag,
the whole point of generics is the compile type safety. We are willing to prevent some scenario from working to achieve it.

As for my original goal is to create a workaround for covariant/contravariant generics.

I'm willing to be able pass instance of single object to methods that will expect ICollection<TStruct> or ICollection<TStruct?>.

As well - I'm willing to get some performance savings to avoid wrapping real TStruct objects into TStruct? before method calls.

As for unification - I'm offering to change this error to warning - and throw runtime exception if user trying to instantiate generics with params that will unify.
Just like current BindGenericArguments do if you pass wrong arguments.

Example:
    class Test<TStruct> where TStruct : struct { }
    class Program
    {
        static void Main(string[] args)
        {
            Type t = typeof(Test<>);
            t.BindGenericParameters(typeof(Program));
        }
    }
This will result in ArgumentException.

Thanks in advance

Hi, thanks for logging this.

The algorithm for deciding which types unify becomes quite complex when you consider all the permutations of possible constraints. In many cases it is not even doable because the type system is unbounded and you don't really know if there will ever be a case in the future when a particular type won't implement a certain interface (for example). This begs the question of which cases our algorithm should recognize and which cases it shouldn't. As we often do, we opted for simplicity and we decided not to consider constraints in the unification (or the applicability) algorithm (as 20.3.1. in the spec describes).

As a curiosity note, what are you trying to achieve by making your class inherit from ICollection<TStruct> and ICollection<TStruct?>?