Opinion on possible need for Higher-Level Generics

[Unknown6656]

Introduction / Motivation

I am currently re-visiting older code from a Mathematics-Library that I have written and I decided to update and refractor it.
However, I stumbled upon the following problem:

Imagine an abstract class representing an topological algebraic ring.
It would have to define an 0-element, a 1-element and the operators + and *. It would look something along these lines:

abstract class Ring
{
    static Ring Zero { get; }
    static Ring One { get; }

    abstract Ring MultiplicativeInverse { get; }
    abstract Ring AdditiveInverse { get; }
    
    abstract Ring Add(Ring other);
    abstract Ring Multiply(Ring other);

    Ring Subtract(Ring other) => Add(other.AdditiveInverse);
    Ring Divide(Ring other) => Multiply(other.MultiplicativeInverse);
    // ...
}

For now, everything seems more or less OK, doesn't it?

Now Imagine, you want to implement the following "inheritance tree"

Function
  Λ
  |
ContinuousFunction
  Λ            Λ
  |            :
 ...           :
               :
               :
 Set           :    // contains a zero element, and a sense of comparison and equality
  Λ            :
  |            :
Group          :    // implements + and has a concept of additive inverse numbers
  Λ            :
  |            :
Abelian Group  :    // has commutativity for +
  Λ            :
  |            :
 Ring          :    // contains an one-element, implements *
 Λ  Λ          :
 |  |          :
 | PolynomialRing   // defines scalar multiplication, has a base (1, X, X², X³, ...) and therefore a dimension
 |       Λ
 |       :
Field    :          // has a concept of a multiplicative inverse
 Λ       :
 |       :
VectorField         // defines scalar multiplication and base/dimension
 Λ
 |
MatrixField         // ...
 Λ
 |
...

You can imagine, how this can quickly go out of hands. Even more - it will be an utter nightmare, if you do not want only to implement such algebraic, topologic and analytic concepts in form of double-somethings (e.g. DoubleFunction, DoublePolynomialRing etc.) - but generic, so that types like int or Complex could also be supported ....
The implementatinos of the types described above would all look as follows:

class DoubleRing
    : Ring
{
    static Ring Zero { get; } = new DoubleRing(0d);
    static Ring One { get; } = new DoubleRing(1d);

    override Ring MultiplicativeInverse => new DoubleRing(this._value);
    //       ^~~~
    //    Why the hell must this be the base class 'Ring'? Why can't I return the implementation (in this case 'DoubleRing')

    ...
}

class ComplexRing
{
    ...

    override Ring MultiplicativeInverse => new ComplexRing(this._value);
    //       ^~~~
    //    Same problem as above.

    ...
}

...

What I wish for next Christmas (or earlier)

It would be fantastic to have some sort of generic concept, which allows the reference of the child type* in definitions. (With 'child type' I mean the type, which will implement the current one.)
One example could look as follows:

abstract class/*?*/ Ring<T>
    : AbelianGroup<T>
{
    static child Zero { get; }
    static child One { get; }

    abstract child MultiplicativeInverse { get; }
    abstract child AdditiveInverse { get; }
    
    abstract child Add(Ring other);
    abstract child Multiply(Ring other);

    child Subtract(child other) => Add(other.AdditiveInverse);
    child Divide(child other) => Multiply(other.MultiplicativeInverse);
    // ...
}

The keyword child would now represent the opposite of base - in the sense that it refers to the type, which will implement the current one ...

Of course, this would be highly complicated to implement in the CLR and the compiler pipeline, so I propose the following:

• Extend the proposal Exploration: Shapes and Extensions #164 (Shapes and Extension) to allow some kind of self/child-referencing in type definitions
• Impelement Multiple Inheritance (Add multiple inheritance #1212) and/or default Interface methods (Champion "default interface methods" (16.3, Core 3) #52) in order to allow the creation of more complex type dependency trees
• Implement some higher-order form of generics or possibly generics on generics (related issues: Higher Kinded Polymorphism / Generics on Generics #339 and First class polymorphism / Rank-N types #549)

---

What do you think? Does C# need stuff like this?
Should it stay more to the "classical" OOP-Style?
Should it -as I think- provide a more functional type-definition system? (e.g. shapes, generic union types, recursive types, ....)

Please Discuss!

[CyrusNajmabadi]

This is a prime case for what Shapes should be used for.

[jveselka]

Some of Your problems could be solved by covariant return #49

[svick]

Extend the proposal #164 (Shapes and Extension) to allow some kind of self/child-referencing in type definitions

How is the current proposal for shapes insufficient for this? The proposal even includes an example that's very similar to yours (it's a group and not a ring, but I don't think that makes a difference).

The only thing missing is (multiple) inheritance between shapes, which doesn't seem to be explicitly mentioned by the shapes proposal. But type classes, which form the basis of that proposal, support it. So I expect multiple inheritance of shapes will be supported.

[TonyValenti]

I've run into this problem and I've made things work using extension methods. For example,

public class BaseClass { 
   public string BaseProperty {get; set;}
}

public class DerivedClass : BaseClass {
  public int DerivedProperty {get; set;}
}

public static class MyExtensions {
  public static T Add<T, U>(this T This, U Other) where T:BaseClass, new() where U:BaseClass {
    return new T();
  } 
}

[gafter]

See #110 for a proposal (with working prototype) that supports this.