Introduce syntax for defining generic type argument constraints that would allow all implementations of a particular generic interface regardless to the interface type parameters used and enable the latter to be used in the resulting generic definition.

[ekaggata]

The task

Introduce syntax for defining generic type parameters constraints that would allow all implementations of a particular generic interface regardless to specific types used in the interface implementation (without the requirement for them to be specified) but make those available for referencing in the generic type definition (implicitly import type parameters of generic interfaces used as a new generic type parameters constraints into the generic type definition scope).

Example

What I mean is to make it possible to define, for example, a generic type ClassB<TA> that would let the TA type parameter to be assigned any type implementing a generic interface IInterfaceA<TB> in whatever a way [the interface definition allows], leaving the the actual type (being used as TA) to be specified at the instance definition place only, without including TB as a parameter in the signature of ClassB itself (what, I believe, means letting to avoid requiring unnecessary [for maintaining strong-typing non-ambiguity] limitations to be set and reducing definition redundancy) while, at the same time, keeping it possible to implement the resulting class logic still leveraging full awareness of what types are actually being used and being able to access (unless restricted another way) the members defined with these types freely.

E.g. something like the following (the example has been made as simplistic as it could be made to provide a self-explanatory C#-alike pseudo-code illustration for the very concept of the functionality being offered for consideration in the most pure manner possible and is not meant to demonstrate potential benefit from its possible usage in a practical use case nor to be comparable with currently available C# compiler implementations) but syntactically and semantically correct:

public interface IInterfaceA<TB>
{

TB TheProperty {get; set;}

}

public class ClassB<TA> where TA : IInterfaceA<TB>
{

TA TheProperty {get; set;}

TB ThePropertyProperty => TheProperty.TheProperty;

}

Given this example it can probably be worth emphasizing on that a particular type to be assigned to the TA parameter at the instance definition time can happen to be a non-generic class, a completely-defined implementation of IInterfaceA<TB> excepting no type arguments already, I believe this remark can explain why a less-verbose alternative to the ClassB<TA, TB> where TA : IInterfaceA<TB> syntax mentioned below can be useful at all.

Potential problems

As @vyrp has suggested at StackOverflow.com an ambiguity can take place if one class implements the same generic interface (the one we require) twice with different type parameters.

Existing alternative

As for now I am using an alternative definition similar to the following as a work-around to solve the same task I would like to use the above-described feature to:

public class ClassB<TA, TB> where TA : IInterfaceA<TB>
{

TA TheProperty {get; set;}

TB ThePropertyProperty => TheProperty.TheProperty;

}

This gets the job done a way but I would like to humbly offer an idea of introducing what can be potentially considered a more elegant syntax for this semantics expression for the team consideration.

[svick]

I think one issue with this proposal is that it can easily lead to wrong code in the presence of typos. Consider:

public class MyClass<TCollection, TValue> where TCollection : IEnumerable<TVlaue>
{ }

I believe this would be valid code if this proposal was accepted, but it's wrong because of the TVlaue typo.

Maybe improved type parameter inference (similar to #289) could help? E.g. when you declare your ClassB<TA, TB>, you will be able to reference it as ClassB<IIinterfaceA<int>,> instead of ClassB<IIinterfaceA<int>, int>, as required today.