Proposal: 'this' generic type constraint to achieve a THISTYPE type

[SamPruden]

where T: this generic type constraint

Porting from dotnet/roslyn#11773 as while the proposal received minimal attention initially it's been a little more active recently. The text here is partially copied over and partially rewritten.

Summary

Note: TSelf is used as the type parameter name by convention here, but any name may be used.

The where TSelf: this generic constraint would be applicable to abstract classes and interfaces only. Type parameters with the this constraint would be constrained to being either the deriving type itself, or a further this constrained type parameter on the deriving type. When used outside of derivation (e.g. to type a variable) further derived children would also be allowed. I am no longer particularly convinced of the value of the struck-through feature! It represents a departure from existing generics behaviours (hopefully the only one) with little obvious return. It remains in other places in this document for now, but may be removed.

Motivation

TL;DR: This is an attempt to vanquish Eric Lippert's evil dog, and to annoy physicists by violating thermodynamics to unbake a noodle.

Safe use of the (sort of) Curiously Recurring Template Pattern. Eric Lippert gives a pretty good overview and critique of this pattern on his blog. I believe this proposal addresses and solves every problem Lippert raises.

One of the main problems with the current use of the CRTP without the this constraint is that it's not safe, a consumer can fail to supply itself as the generic parameter. As such, this pattern while sometimes okay to use internally, is rarely reasonable to expose across an API interface. This constraint would fix that.

Another common issue is that the code is confusing. With this constraint in place the compiler and IntelliSense would enforce correct behaviour and remove ambiguity, mostly fixing this.

I've found myself wishing for this a number of times over the last few years. I suspect the primary use cases would be in more framework like libraries than business logic.

A side-effect of this would be that an interface could restrict the types to which it can be applied. where TSelf: this, Foo would mean an interface can only be applied to class Foo and its children, and where TSelf: this, IBar would mean the interface could only be applied to types that also implement IBar. While not exactly the primary intention behind this feature, I actually think this could be a nice thing to have when building strong APIs with specific consumption of interfaces in mind.

A few simple scenarios where this may be useful

Each derived type is comparable to itself but not to other derived types.

abstract class BaseType<TSelf> : IComparable<TSelf> where TSelf: this {}

As a slight variation, this would require deriving types to implement the interface themselves.

abstract class BaseType<TSelf> where TSelf: this, IComparable<TSelf> {}

All derived types provide a strongly typed static default.

abstract class BaseType<TSelf>
    where TSelf: this, new()
{
    public static TSelf Default { get; } = new TSelf();
}

I've had a few scenarios in my time (including one in a pet project right now actually) where I have other bits of API that are generic that I'd like to be able to call like this.

abstract class BaseType<TSelf>
    where TSelf: this
{
    public void DoACoolThingBro()
    {
        SomeStaticType.SomeCoolGenericAPI<TSelf>();
    }
}

Detailed design

Interfaces and abstract classes can use the derived type

interface IClonable<TSelf>
    where TSelf: this
{
    TSelf Clone();
}

Interfaces and abstract classes can apply constraints to derived types

abstract class Duplicatable<TSelf>
    where TSelf: this, new()
{
    public TSelf Duplicate()
    {
        // All derived types must provide a default constructor
        return new TSelf();
    }
}

Static class members can use the derived type

abstract class SomeServiceType<TSelf>
    where TSelf: this, new()
{
    // All derived types now provide a static default
    public static readonly TSelf Default = new TSelf();
}

A concrete derived class must pass itself as the type argument

abstract class Base<TSelf> where TSelf: this {}

class Derived : Base<Derived> {}

An abstract derived class or interface may pass itself or a further : this parameter of its own as the this argument

abstract class Base<TSelf> where TSelf: this {}

abstract class Derived : Base<Derived> {}

abstract class Derived<TSelf> : Base<TSelf> where TSelf: this {}

When not declaring implementations (for example in variables, fields) indirectly derived types may be used as arguments

This part of the proposal is possibly the weakest. I'm not sure how much value it provides, and it represents a bit of a departure from existing generics behaviour. This should probably be removed.

interface IBase<out TSelf> where TSelf: this {}

class DirectlyDerived : IBase<DirectlyDerived> {}

class IndirectlyDerived : DirectlyDerived {}

void SomeMethodSomewhere()
{
    IBase<IndirectlyDerived> value = new IndirectlyDerived();
}

An extended version of the example from Lippert's blog, updated and annotated with this feature

// A class with a this constrained parameter must be abstract.
abstract class Animal<TSelf>
    where TSelf: this
{
    protected Animal(){
        // this is always TSelf or a child of TSelf.
        TSelf self = this;
    }

    // In Lippert's highly conservative scenario, animals may only make friends with their own kind.
    // THIS METHOD DOES NOT NEED TO BE VIRTUAL
    public virtual void MakeFriends(TSelf animal) {}
}

// A derived class must pass itself, or a pass-through parameter - see Fish<TSelf>.
class Cat : Animal<Cat>
{
    // Tada, Cat can now make friends with other cats, and only other cats.
    // Override included here for demonstration.
    // This method could have been non virtual in the base.
    public override void MakeFriends(Cat cat) {}
}

class CatWithBell : Cat
{   
    // Back to normal inheritance behaviour here.
    public override void MakeFriends(Cat cat) {}
}

// Here a further type parameter constrained with this is passed through.
// Note also that a new() constraint is placed on all directly implementing types.
// A class cannot directly inherit from Fish<TSelf> without meeting the new() constraint.
abstract class Fish<TSelf> : Animal<TSelf>
    where TSelf: this, new()
{
    // Fish are extra snooty and only make friends with their exact species.
    public override void MakeFriends(TSelf fish) {}

    // But they will at least politely wave at any other fish.
    public virtual void GreetFish<TFish>(TFish fish)
        where TFish : Fish<TFish>
    {}

    // Fish are made in factories right?
    public static TSelf MakeFish()
    {
        return new TSelf();
    }
}

class Trout : Fish<Trout>
{
    // Trout only make friends with trout.
    public override void MakeFriends(Trout trout) {}

    // Can greet any other fish.
    public override void GreetFish<TFish>(TFish fish)
        where TFish : Fish<TFish>
    {}
}

// Back to normal inheritance behaviour.
class TroutWithSunglasses : Trout
{
    // Does not meet the new() constraint defined in Fish<TSelf>. This is allowed.
    public TroutWithSunglasses(bool looksCool)
    {
        if (!looksCool) throw new ArgumentOutOfRangeException();
    }
}

// DOES NOT COMPILE
// This compiles in the example on Eric Lippert's blog. Here it does not.
//class EvilDog : Animal<Cat>
//{
//  public override void MakeFriends(Cat cat) { }
//}

void UsageDemo()
{
    Cat cat = new Cat();
    CatWithBell catWithBell = new CatWithBell();
    Trout trout = new Trout();
    TroutWithSunglasses troutWithSunglasses = new TroutWithSunglasses(true);

    // Cat satisfies Animal<TSelf>'s constraints so can be used here.
    Animal<Cat> animalCat = cat;
    // This all functions as normal.
    animalCat = catWithBell;

    // While not directly derived, CatWithBell still meets the constraints.
    Animal<CatWithBell> animalCatWithBell = catWithBell;

    // DOES NOT COMPILE
    // While it does still derive from Fish<TSelf>, TroutWithSunglasses does not meet the new() constraint.
    //Fish<TroutWithSunglasses> fishTroutWithSunglasses;
}

Drawbacks

This would (I believe) require a CLR change.

Unresolved questions

Is there any way this could be made to work with non abstract virtual base classes?

Should some shorthand be provided to make defining derived classes nicer? Credit to @CodeSingularity for spawning this train of thought in the old issue.

class LongConvolutedMessyClass<TKey, TValue, TPizza, TMilk> : SomeBaseClassWithTSelf<this> {}

could expand into

class LongConvolutedMessyClass<TKey, TValue, TPizza, TMilk> : SomeBaseClassWithTSelf<LongConvolutedMessyClass<TKey, TValue, TPizza, TMilk>> {}

Should we be allowed to access implied members?

abstract class SomeBaseClass<TSelf> where TSelf: this, IDisposable {}
abstract class SomeDisposableClass: SomeBaseClass<SomeDisposableClass>, IDisposable { ... }

void Test() {
    SomeDisposableClass disposableClass = new SomeDisposableClass();
    SomeBaseClass<SomeDisposableClass> baseClass = disposableClass;

    // This should work absolutely fine.
    disposableClass.Dispose();

    // Should this work? 
    // Dispose() does not exist on the base type, but it is guaranteed to exist for every concrete type.
    baseClass.Dispose();
}

[SamPruden]

I have just edited in a few clearer and more broken up parts to the detailed design section.

I have also edited the summary to indicate a potential revision. I am no longer convinced that indirectly derived types should be passable as TSelf when declaring variables/fields/members as this represents a departure from existing generic behaviour and provides very limited value. I have however only made this edit to the summary and left the feature in other places in the document for the time being as I'm not completely sure. If anyone has any thoughts on this matter I'd be interested.

[TomasJuocepis]

I'd love to see this feature. I've been using CRTP more and more frequently as I got more familiar and comfortable with it, but only internally so far and not for any externally consumable APIs.

My favorite example use case for this is base Enumeration class, which allows consumers to derive it and inherit functionality similar to Java enumerations - each instance of a derived class gets an ordinal number and a string name properties, as well as overriden toString method and implicit casts to int and string, while each derived type itself gets a static property with a collection of all enumerations as well as static methods/index operators to access an enumeration by int or string value.

This allows creating OO style enumerations with minimal boilerplate code. Some examples:

// Basic example

public class ChessPiece : Enumeration<ChessPiece>
{
    public static readonly ChessPiece
        King = new ChessPiece("King", 1, double.PositiveInfinity),
        Queen = new ChessPiece("Queen", 1, 9),
        Rook = new ChessPiece("Rook", 2, 5),
        Bishop = new ChessPiece("Bishop", 2, 3),
        Knight = new ChessPiece("Knight", 2, 3),
        Pawn = new ChessPiece("Pawn", 8, 1);

    public readonly int StartingCount;
    public readonly double RelativeValue;

    private ChessPiece(string name, int count, double value) : base(name)
    {
        StartingCount = count;
        RelativeValue = value;
    }
}

// example use case - having static collection of all enumerations:
double totalStartingValue = 0;
foreach (ChessPiece chessPiece in ChessPiece.Values)
    totalStartingValue += chessPiece.StartingCount * chessPiece.RelativeValue;

second example:

// Example: strategy pattern with enumerations:

public abstract class DateRangeConvention : Enumeration<DateRangeConvention>
{
    static DateRangeConvention() { EnumerationName = "Date Range Convention"; }

    public static readonly DateRangeConvention
        TO = new ToConvention("To"),
        THROUGH = new ThroughConvention("Through");
    
    private DateRangeConvention(string name) : base(name) { }

    public abstract int DayCount(DateTime startDate, DateTime endDate);


    // PRIVATE DERIVED CLASSES (ENUMERATIONS)

    private class ToConvention : DateRangeConvention
    {
        public ToConvention(string name) : base(name) { }
        public override int DayCount(DateTime from, DateTime to)
        {
            return (to - from).Days;
        }
    }

    private class ThroughConvention : DateRangeConvention
    {
        public ThroughConvention(string name) : base(name) { }
        public override int DayCount(DateTime from, DateTime through)
        {
            return (through - from).Days + 1;
        }
    }
}

[SamPruden]

@TomasJuocepis
Yeah, that's not dissimilar to the types of use cases I often come across myself. I tried to keep the examples simple in the proposal because I didn't want to make it seem niche, but I've found many more complex and powerful use cases when putting together frameworks for games engines, particularly in building nice APIs for entity/component systems. Any API that's consumed by derivation is a good candidate for getting some really nice uses out of this.

[CodeSingularity]

I too use this pattern very frequently, it's very useful.

In my extension method library the most prominent example is my class PropertyHistoryBase which manages all INotifyPropertyChanged handling and tracks history for each property. I then query the history using an expression.

public abstract class PropertyHistoryBase<TSelf> : PropertyBase
where TSelf : PropertyHistoryBase<TSelf>
{
public History History { get {...} } 

public class History
   {
   public ObservableCollection<TimestampedPropertyChangedEventArgs> this[Expression<Func<TSelf, object>>] 
      {get {...}}
   }
}

public class PropertyExample : PropertyHistoryBase<PropertyExample>
{
public string SourceProperty
   { 
   get => this.Get<string>();
   // handles all INotifyPropertyChanged
   set => this.Set(value);
   }

// triggers the notification from the local property, and notifies event subscribers 
// if there are remote objects subscribed to the property
[NotifySource(nameof(SourceProperty))]
public string DerivedProperty => $"{SourceProperty} derived";
}

Example:

propertyInstance.History[o=> o.DerivedProperty]

[Richiban]

Can this proposal be expanded into simply being able to use this as a type, anywhere? It would make a number of cases much easier to read / understand, such as implementing your own value objects:

public class MyData : IEquatable<this> { ... }

Fluent method chaining:

public this WithName(string name) { ... }

in addition to the aforementioned ability to use it as a type constraint:

public T GetData<T>() where T : this { ... }

[SamPruden]

@Richiban

What you're describing is approximately #252. If you look there you'll see some discussion between myself and @phi1010 regarding the relative merits of each approach. In short, the answer to your question is "maybe". The functionality you're talking about would be nice, but it's a significantly larger feature to implement.

This proposal effectively (this is a little simplified) just adds a compiler check to enforce the constraint, and otherwise relies on existing language features. The more comprehensive version (what you're advocating) would need many more changes, including significant syntax/parsing changes and other internal stuff that's a bit out of my comfort zone to talk about.

So in conclusion, what you're advocating would be great, this would be easier. Perhaps this could be implemented first, and the other features could be added at a later date. Do go and vote on that one (and this one if you don't hate it) and let's hope we can get at least some version of this sometime soon.

[dcnetfan]

Thank you for opening this subject, for me it is one of the most important features that I would like to see it available into C#.
Guys, please make this available! It is really valuable feature!

[thomaslevesque]

If I understand this proposal correctly, the whole point of this feature would be to make CRTP safer. But CRTP is just a (rather awkward) crutch for a common problem, so it feels wrong to add a feature that would make it safer, but no less awkward. I'd rather see something that would make CRTP unnecessary.

[andrey-messi]

@SamPruden

1

Interfaces and abstract classes can use the derived type

Why only abstract classes? It seems to be applied to any kind of classes (except sealed).

2

A concrete derived class must pass itself as the type argument

abstract class Base<TSelf> where TSelf: this {}
class Derived : Base<Derived> {}

I think that to write
class Derived : Base<Derived>{}
is too redundantly. To write:
class Derived : Base {}
is sufficiently. But because we can omit a type parameter with 'this' constraint then this parameter always should place in the last position in a list of type parameters, for example:

// invalid
abstract class Base<TSelf, T1, T2> where TSelf: this {}
// valid
abstract class Base<T1, T2, TSelf> where TSelf: this {}
class Derived : Base<string, string> {}

3

class Cat : Animal<Cat>
{
    public override void MakeFriends(Cat cat) {}
}
class CatWithBell : Cat
{   
    public override void MakeFriends(Cat cat) {}
}

A CatWithBell can make friends with a Cat. And if I want that a CatWithBell can make friends only with other CatWithBell then I should change code above to that?

class Cat<TSelf> : Animal<TSelf>
    where TSelf: this
{
    public override void MakeFriends(Cat cat) {}
}
class CatWithBell : Cat<CatWithBell>
{   
    public override void MakeFriends(CatWithBell cat) {}
}

But what if I write that?
class Cat<TSelf> : Animal<Cat<TSelf>>
What changes?

4

    // Should this work? 
    // Dispose() does not exist on the base type, but it is guaranteed to exist for every concrete type.
    baseClass.Dispose();

I think it obviously shouldn't work because this class
SomeBaseClass<TSelf>
is not reailizing IDisposable.

[Pzixel]

While this proposal fiits in the current language, I believe it's wrong that Animal is generic at all. It have nothing he abstracts on.

After working some time with language like Rust I see that we just need a keyword this applicable at level type that returns the most specific type. CLR allows it, it already was discussed somewhere.

Thus I'd like to just type:

abstract class BaseType
{
    public static this Default { get; } = new this();

    protected BaseType() {} // make sure we have a default constructor
}

If you place it in generics you have them spreaded up in all your system, you start writing generic methods just to access these animals, however it's clear that for example CatWithBell should be called because it's of type this, but actually Cat is. Isn't it confusing that Default is of another type than this? I also would be confused if I write typeof(T) != this.GetType() which is also was shown in this example.

---

Alternatively, look at Rust depended types:

trait Clone {
    fn clone(&self) -> Self;
}

Clean, honest declaration. We don't need generics here because we have no generic parameter. We actually need nothing else because it's ok as it is.

I don't mind if it would be implemented via generics with some attribute to prevent user from diving into them, but writing it manually is a nightmare.

[jnm2]

@Pzixel This doesn't make sense to me, since the same static field in the base class (Default) is shared by all derived classes. The same static field can't be one type when accessed through BaseType and another type when accessed through DerivedType.

// ReSharper suggests that you correct this to BaseType.Default
// since they are two names for the same single field.
var x = DerivedType.Default;

// Outputs "true"; same field, holding the same instance, no matter how the name was qualified.
Console.WriteLine(ReferenceEquals(x, BaseType.Default));

abstract class BaseType
{
    public static this Default { get; } = new this();

    protected BaseType() {} // make sure we have a default constructor
}

class DerivedType : BaseType
{
}

[Richiban]

@jnm2 You're right; it's not going to work with static members (at least, not inherited ones).

This feature is applicable more to Shapes, I feel.

[Pzixel]

@jnm2 the problem is that we have no way to constraint against static methods. We cannot write interface

public interface IParseable 
{
   public static this Parse(string input);
}

This is why it looks ugly.

I can propose to just shadow base declarations. E.g. it this code

abstract class BaseType
{
    public static this Default { get; } = new this();

    protected BaseType() {} // make sure we have a default constructor
}
class DerivedType : BaseType
{
}

class DerivedDerivedType : DerivedType
{
}

Compile into this:

abstract class BaseType
{
	public static BaseType Default { get { throw new InvalidOperationException(); } }

	protected BaseType() { } // make sure we have a default constructor
}

class DerivedType : BaseType
{
	public static DerivedType Default { get; } = new DerivedType();
}

class DerivedDerivedType : DerivedType
{
	public static DerivedType Default { get; } = new DerivedDerivedType();
}

Again, this doesn't look good, but again we have no abstract for static members. It's just a direction. Another thought: it's just how it could be implemented, on a source code level it's fine, except that it may be a bit confusing when you're trying to get this property via reflection, but again, it's learnable.

[jnm2]

It's counter-intuitive for an arbitrary number of static fields to be generated when you replace the field type with a keyword. How common is this scenario?

[Pzixel]

@jnm2 happens quite often to me.

For example I have following class:

public abstract class ContractBase
{
	protected readonly Web3 Web3;
	public string Address { get; }

	protected ContractBase(Web3 web3, string address)
	{
		Web3 = web3;
		Address = address;
	}

	protected Nethereum.Contracts.Contract Contract => Web3.Eth.GetContract(Abi, Address);

	protected abstract string Abi { get; }
}

And I have to hold Abi in separated class

public static class Abi
{
	public static string SeasonFactory { get; } = XResource.ReadResource(nameof(SeasonFactory), "abi");
}

And then use it in derived class

public class SeasonFactory : ContractBase
{
	public SeasonFactory(Web3 web3, string address) : base(web3, address)
	{
	}

	public static async Task<SeasonFactory> DeployAsync(Web3 web3, params object[] values)
	{
		var receipt = await web3.Eth.DeployContract.SendRequestAndWaitForReceiptAsync(Core.Abi.SeasonFactory, Core.Bin.SeasonFactory, web3.TransactionManager.Account.Address,
																					  new HexBigInteger(4600000), values: values);
		return new SeasonFactory(web3, receipt.ContractAddress);
	}

	protected override string Abi => Core.Abi.SeasonFactory;
}

Note that DeployAsync have to know Abi before creating an instance.

So I'd like to write following:

public abstract class ContractBase
{
	protected readonly Web3 Web3;
	public string Address { get; }

	protected ContractBase(Web3 web3, string address)
	{
		Web3 = web3;
		Address = address;
	}

	protected Nethereum.Contracts.Contract Contract => Web3.Eth.GetContract(Abi, Address);

	public static string Abi { get; } = XResource.ReadResource(nameof(this), "abi");
	public static string Bin { get; } = XResource.ReadResource(nameof(this), "bin");
}

And then have:

public class SeasonFactory : ContractBase
{
	public SeasonFactory(Web3 web3, string address) : base(web3, address)
	{
	}

	public static async Task<SeasonFactory> DeployAsync(Web3 web3, params object[] values)
	{
		var receipt = await web3.Eth.DeployContract.SendRequestAndWaitForReceiptAsync(this.Abi, this.Bin, web3.TransactionManager.Account.Address,
																					  new HexBigInteger(4600000), values: values);
		return new SeasonFactory(web3, receipt.ContractAddress);
	}
}

And completely remove these separated Abi and Bin classes. Now I have to keep them consistent and override proper item. I can't incapsulate them because the best I can is make abstract method which is not available in static contexts where it's actually is needed.

[Pzixel]

Did you consider to expand this into full associated types? LIke:

interface IComparableRight {
   type T = this;
   
   public bool Compare(T other)
}

[333fred]

For this particular proposal? I haven't seen that. There is a proposal for associated types though: #1328.

[Pzixel]

Yep, didn't see this feature, probably because of strange syntax there. Thanks for linking. Hope it will be championed.

[SamPruden]

Did you consider to expand this into full associated types? LIke:

interface IComparableRight {
   type T = this;
   
   public bool Compare(T other)
}

Associated/existential types as in #1328 look like a very nice feature that may (I would need to think about it more) be able to achieve the goals of this proposal, but I wouldn't consider merging them into this. This proposal was designed to be the smallest and least disruptive change that could achieve safe CRTP type behaviour. There are more advanced proposals that could also achieve that goal along with others, but that have a higher barrier to implementation. I think it's good to have a range of possible routes to something like this.

[MithrilMan]

How did this subject evolved?

[CyrusNajmabadi]

@MithrilMan when updates happen, they will be added to the discussion.

[warquys]

The new Gerneric Maths Interface use this kind of practice.
When the class implementing the interface do not give the itself as gerneric paramaeter a warning occure CA2260.

I don't know where the code analyzer for this is located. But is it possible to generalize the to an attribue ?
Or implement this new key word : this.

The CLR already supports this, however, exepete it also accepte things that we wouldn't want. A Warning or Error would be a real plus if the implementation is not right, like:

[System.AttributeUsage(AttributeTargets.GenericParameter | AttributeTargets.Class, Inherited = true, AllowMultiple = false)]
public sealed class SelfAttribute : Attribute;

public abstract class Base<[Self] TSelf> where TSelf : Base<TSelf>;

public class Foo : Base<Foo>;

// Error here
public class Bar : Base<Foo>;

I also try:

public class Base<[Self] TSelf> where TSelf : Base<TSelf>, IDisposable;

// CS0311
public class Foo : Base<Foo>;

There is already the fact of forcing the derived member to implement interfaces. However, Intellisense does not offer a clear solution. Making Intelisence propose as a solution to implement the interfaces would make it more compressible and a time saving.

Personally, I prefer a valid keyword for abstract classes and interfaces rather than having to make a Generic class.
Like say by Pzixel.