Support Inheriting from Generic Type (CS0689)

[UniqeId6542]

Change .NET and C# to support inheriting from a generic type. (i.e. current compiler error CS0689)
This has been requested in forums before.

• https://stackoverflow.com/questions/3047830/how-to-inherit-from-a-generic-parameter
• https://stackoverflow.com/questions/47617372/inherits-from-anonymous-type-t
• https://stackoverflow.com/questions/1420581/inheritance-on-a-constrained-generic-type-parameter

I believe it would be useful to extend common functionality to a variety of classes - even when that functionality requires backing data. And it would be better (and more exacting) solution than using a ConditionalWeakTable with extension methods.

Implementation challenges
I don't why defining types at runtime (or something...) would make this harder than using C++ templates to do the same thing. How is it substantially different than two dlls making a List<object> that ends up as a single type?
There would have to be some way to define 'make a base call' (either a dynamic call, or generating code when loading) rather than a static call - so that different base class implementations of a method could be called.

Monads
I only know a little about this concept, but I think that this style of inheritance would better support monads. If I want to extend the functionality of a class or interface, I can currently write extension methods. But those don't support state information. (Or make some hack with a ConditionalWeakTable) Unfortunately many of the interesting extensions that I've wanted to do require some state to be saved. This would be a natural way to extend a range of classes.

[svick]

This would certainly be quite a significant change, so I think to even start the discussion, you would need to:

1. Explain why this is needed and why the existing alternatives are not sufficient.
2. Describe how it would work in the context of the .Net type system. (Saying that it works in C++, so it should be possible to do it in .Net is not enough.)

[UniqeId6542]

1. I have several implementations of an interface. I now have a new use case that needs more data. I could add the data to a base class (which is adding 'global' overhead for a narrow use case) or I could inherit from all the type specific implementations to make a new set of classes with the added data (lots of classes and not DRY). I could add an extension method backed by a ConditionalWeakTable, but that adds other overhead and would similar to updating the base class - from an external perspective.
   As a generality, I think since people have asked for this multiple times (as given in the links) that there is a 'broad' desire for this functionality.

2. If this doesn't answer your question, I would appreciate links that explain the .NET type system - so I can give a better answer.
   Currently, generics of the same type are the same class (List<string> is the same across dlls)
   This would be the same (FooExt<Foo> would be the same across dlls)
   But, there would probably have to be different classes for different base-classes. FooExt<T> would produce different classes depending on the base class. (FooExt<FooA> and FooExt<FooB> would probably be two different derived classes for the two different base classes)
   Contravariance would be needed in interfaces. 'IFooExt<IFoo> localVar' has to be able to hold both FooExt<FooA> and FooExt<FooB>. Though, I could imagine that FooExt<IFoo> (class derived from interface) would be disallowed.

[cupronickel]

i can tell one use case where it will be usefull. I wan to realize a feature like temporal table from mssql but in postgresql. there is two entities - main and historical, each lays in its tables, but they are identical by parameters. so, i want to describe historical entities like
"public class HistoricalEntity : T {}" and dynamicaly register it in entity framework like copy of registration of main entity, except table to save

[teo-tsirpanis]

would make this harder than using C++ templates to do the same thing

Keep in mind that C++'s templates are implemented in a fundamentally different way than .NET's generics.

[UniqeId6542]

Keep in mind that I said:

I don't [know] why defining types at runtime...

And it is under the section

Implementation challenges

I never suggested that generics are implemented similarly between C++ and .NET.
If you understand why (or, what about) the .NET implementation of generics makes this request difficult, I would appreciate a link to an explanation.

[stevefan1999-personal]

C++ templates have monomorphization, which means generating code for specific generic application into concrete type, i.e. Foo<int> as a concrete type. As far as I know, C# generics does not yet support monomorphization, but it is definitely possible given how it is doing well with NativeAOT.

[UniqeId6542]

Yeah, I think that something like that will have to be done.
Currently IL has an OpCode 'Constrained' that can prefix a 'callvirt' - to allow a generic type to call a method that might be on a class or struct. Something similar will have to be done for base class calls.
A new OpCode would probably have to be added. It would either be replace at runtime or by the compiler once the concrete type is known.

[TacoConKvass]

I would love this feature as a way to reduce boilerplate code when extending types from external assemblies. Let's assume thus example situation:

// Base classes from an external assmebly
public class Base { }

public class A : Base
{
    public Type Field;

    public virtual Type Method() { }
}

public class B : Base
{
    public Type OtherField;

    public virtual Type OtherMethod() { }
}

// My own project
public class Extended<T> : T where T : Base {
    public Type NewField;
}

// Apart from inheriting 
public class SuperA : Extended<A> { }

public class SuperB : Extended<B> { }

While accessing/overriding members inherited specifically from T, and not Base in the Extended<T> class would be reasonably disallowed, as it is unknown what exactly those are, adding new fields shared between inheriting classes could prove useful. SuperA and SuperB would be able to override the A::Method and B::OtherMethod respecively, as it is known from which types those inherit at compile time.