Constructed type reference

[Logerfo]

Disclaimers

Feel free to suggest a better name for this feature.
This feature was first suggested at #49 (comment), as it overlaps with "Covariant Return Types", but they are now split since there are use cases only covariant return types can achieve and use cases only constructed type reference can achieve.
As stated by @HaloFour at #49 (comment), this proposed feature probably requires CLR changes (#317).

Introduction

CRTP allow developers to achieve some next level generic code, but it comes at a price, like the following:

class Animal<T> where T: Animal<T>, new()
{
   public T[] Parents { get; private set; }
   public T Breed(T other) => new T
   {
      Parents = { this, other }
   };
}
class Dog : Animal<Dog> { }
class Person
{
   public Animal[] Pets { get; } //not possible
}

Proposal

What if C# had this T type for the constructed type out of the box, without the need for an actual generic enclosing type? Like this:

class Animal
{
   public TConstructed[] Parents { get; private set; }
   public TConstructed Breed(TConstructed other) => new TConstructed
   {
      Parents = { this, other }
   };
}
class Dog : Animal { }
class Person
{
   public Animal[] Pets { get; } //now possible
}

Open questions

• TConstructed is just a placeholder here. How should it be called? Also, a currently non-reserved keyword would be a breaking change for classes that already have a defined member with the same identifier, unless any identifier hid the one this feature designs (just like what I think it happens for discard operators).
  • An ugly suggestion: typeof(this). Besides ugly, it seems inconsistent, because typeof is meant to return a runtime (and not compile time) Type reference. But it would fix the breaking change scenario.
• In my CRTP example, the new() constraint is defined and used, but in the proposal the constructed type does not necessarily match it. At first, this constraint wouldn't be possible for this feature, but that would make it lack some usefulness.
  • Perhaps constraints could be allowed normally for the type reference. This would take this feature to another level, probably overlapping to Champion "Type Classes (aka Concepts, Structural Generic Constraints)" #110 and/or Higher Kinded Polymorphism / Generics on Generics #339, but note that class generic type arguments can be referenced in static methods, while the constructed type reference cannot.

[Richiban]

Your suggestion is also closely related to Shapes #164 which I think will give you what you want.

I agree that this is something that's sorely missing from C#, but it's due to a limitation of the CLR that will hopefully be lifted if covariant return types are implemented.

In my opinion, it's a massive hack that in C# the only way to actually write an IEquatable interface is to make it generic:

public interface IEquatable<T>
{
    bool Equals(T other);
}

This works, but it's a hack because the implementor can pass any type it likes for the T of IEquatable when in fact T should always be the implementor itself.

C# does nothing to prevent you from writing the following jibberish:

public class Foo : IEquatable<DateTime>
{
	...
}

Shapes should hopefully bring some of the features of typeclasses to C#, such as being able to use this in a type position.

Maybe one day:

shape SAnimal : new()
{
   public this[] Parents { get; private set; }
   public this Breed(this other) => new this
   {
      Parents = { this, other }
   };
}

We can but dream.

[HaloFour]

@Richiban

but it's due to a limitation of the CLR that will hopefully be lifted if covariant return types are implemented.

IIRC covariant return types wouldn't require any CLR changes, although it might be cleaner with CLR changes. Without CLR changes it would require a bridge method which overrides the base method and calls the method with the covariant return. This is how Java does it.

[Logerfo]

@Richiban
Reflection-wise, I think Shapes would be a more messy solution for the presented case. Also, I'm not sure it would ever work for generics like M<this>() (maybe I'm wrong in this one since I don't fully understand the shapes concept yet).
Just like for covariant return types, I think my proposal overlaps to shapes, but the three of them have their beauty and could coexist.