Compiler-enforced type-restricted Type

[mqudsi]

There are a lot of open (and closed) issues for suggestions about taking C#'s static type checking to the next level or ideas on improving generic support. This is an RFC/suggestion that should enable a lot of the ideas without dramatically changing how the types are handled within the language itself by extending type-checking to literal Type declarations, such as those via typeof(...).

The suggestion is to add a new type:

class Type<ParentType> : Type
    where ParentType: Type
{ ... }

Which does nothing but hint to the compiler that it should mandate that any instances of this type should refer to types that implement/inherit from the named ParentType (that's a lot of types!).

Given the following code:

public interface ISomething {}
public class A {}
public class B {}
public class Aa : A, ISomething {}

The following code would be legal:

Type<A> handlerType1 = typeof(A);
Type<A> handlerType2 = typeof(Aa);

Type<Isomething> something = typeof(Aa);

but the following would generate a type error during compilation:

Type<A> handlerType1 = typeof(B);

All presumably without breaking existing code or requiring any changes to the generated CLR.

[HaloFour]

@mqudsi

How would you propose that this be implemented?

As of today the C# code typeof(T) emits the IL ldtkn to load the runtime token of the type and then invoke Type.GetTypeFromHandle. Changing that behavior would involve modifying both the CLR and the BCL and would likely introduce breaking changes.

[mqudsi]

@HaloFour presumably it would still continue to do the same, but during the type checking stage after Type.GetTypeFromHandle returns it would validate that the indicated relationship exists?

[HaloFour]

@mqudsi

It has to do more than validate a relationship, it has to cast the result to a different type. But the type returned from Type.GetTypeFromHandle isn't a Type<T> and couldn't be without runtime changes. The compiler would have to support a form of target-typed conversion, like it does for string interpolation or stackalloc, where if the result is assigned to a Type<T> that the compiler attempts to validate the relationship between Type<T1> and typeof(T2) and then converts the Type into the Type<T1>. That's certainly possible.

That all said, what would be the use cases for a feature like this? Java has this feature, where Class<Foo> foo = Foo.class;, but that's used primarily with generics due to the limitations of type erasure which prevent reflection on the generic type arguments. C# doesn't have those limitations, and in C# APIs it would be more normal to accept such a type as a generic type argument than as a normal argument of type Type, e.g.:

Java:

Try<String> t1 = Try.success("hello");
Try<String> t2 = t1.recoverWith(IllegalArgumentException.class, exception -> "world");

C#

Try<string> t1 = Try.Success("hello");
Try<string> t2 = t1.RecoverWith<IllegalArgumentException>(exception => "world");

[YairHalberstadt]

@mqudsi
Can you give an example of a practical use case for this feature?
Thanks