Proposal: overriding generic properties

[Ultrahead]

Consider the following scenario:

public abstract class MyBaseClass<TClass> where TClass: MyBaseClass<TClass> 

public class MyDerivedClass1: MyBaseClass<MyDerivedClass1>{} 

...

public class MyDerivedClassN: MyDerivedClass1 {...}

Once you specify the generic type on a class with a non-abstract parameter, you cap the level of depth on the class hierarchy from that point and on. For the example above that would apply from MyDerivedClass1 and on ...

So my question: could it be feasible to override such limitation for cases where the new type inherits from the previous type? Like, for that example:

public class MyDerivedClassN: override MyDerivedClass<MyDerivedClassN> { ... } 

/// that is, without the need of declaring 
/// public class MyDerivedClass1<TClass>: MyBaseClass<MyDerivedClass> where TClass: MyDerivedClass1<TClass>

Picture it not for that specific example but also in general:

public abstract class MyBaseClass<TParameter> where TParameter: MyParameterBase, new() { ... }

public class MyDerivedClass1 : MyBaseClass<MyParameter1> { ... } // where MyParameter1 inherits from MyParameterBase

public class MyDerivedClassN : override MyDerivedClass1<MyParameterN> { ... } // where MyParameterN inherits from MyParameter1.

Thoughts?

[svick]

What is the use case for this pattern? And since you can already do this and you're just asking for more succinct syntax, are you sure the use cases for this are sufficiently popular?

Also, I don't think the proposed syntax is possible: public class MyDerivedClass1 : MyBaseClass<MyParameter1> already declares non-generic class MyDerivedClass1, so you can't change it to declaring a generic class with constraint.

[VisualMelon]

This doesn't make sense, because MyDerivedClass1 knows that TParameter is an invariant MyParameter1: it can assign TParmeter fields and such which MyDerivedClassN wants to be a sub-type.

You can already achieve the useful behaviour by using more generic types (e.g. MyDerivedClass1<T> : MyBaseClass<T> where T : MyParameter1, new()), which (necessarily) prevents attempting to write/pass MyParameter1s to/as Ts in the middle class (obviously this imposes an overhead for the code consuming MyDerivedClass1<T>, or mandates another class which is just a concrete version of it)

[Ultrahead]

The idea is to avoid having to declare a new generic class like the one you suggest (I've been already there).

It could make sense if you think it as overriding covariant reference types.

[Ultrahead]

I'm a game developer, and I'd use it everywhere -where applicable, when an abstract class with one ore more generic-parameters is declared, and you need to extend a specification (derived class) of such class overriding, for instance, covariant return reference types and properties (services, behaviours, etc.).

So no, I don't think it would be popular enough in the C# community as a whole. But I lose nothing for proposing it.

[quinmars]

Related: #169 and #252

[Ultrahead]

Indeed.

[jnm2]

The title makes me think of @CyrusNajmabadi's “for all intensive porpoises.” 😄

[Ultrahead]

I've edited the first post because I forgot to add the 'override' keyword.

[MadsTorgersen]

This is close to what existential types or associated types can do (known in Scala as abstract types).

I think those are a better way of achieving the "non-generic on the outside, generic on the inside" effect. Beta called it "virtual types", and simply allowed nested types to be overwritten with more derived ones, just like other members.

[Ultrahead]

Understood.

As a workaround I'm partially getting the desired result by defining generic interfaces with covariant parameters and generic delegates with contravariant ones (that are then used in the former to declare events).

[Ultrahead]

#49

[Ultrahead]

Wow! Nice to see Covariant Returns is part of C# 9, which follows the spirit of this proposal. Thanks @MadsTorgersen!