What does the "where" do in interface Addable<T> where T : Addable<T> {}

[ThereIsNoPie]

The following code seems to work a "where" in the Animal interface declaration. I understand why Mammal needs the "where" (otherwise the compiler can't resolve EatLunch).

It seems that louthy puts the "where" on all interfaces. Just wondering if there's additional information I don't understand about the compiler that makes it a good idea to always add the "where".

    public interface Animal<T> 
    {
        public static abstract T EatLunch(T animal);
    }

    public interface Mammal<T> : Animal<T> 
        where T : Mammal<T>
    {
        public static abstract T BeWarm(T animal);
    }

UPDATE:

louthy puts the "where" on all interfaces

Looking at some code, "all" is an exaggeration. But for example the following compiles completely fine without the "where" on the Mappable interface.

    public interface K<F,A>;
    public interface Mappable<F>
    {
        public static abstract K<F, B> Select<A, B>(K<F, A> list, Func<A, B> f);
    }

    public record List<A>(A[] Items) : K<List, A>;
    public class List : Mappable<List>
    {
        public static K<List, B> Select<A, B>(K<List, A> list, Func<A, B> f)
        {
            throw new NotImplementedException();
        }
    }

[louthy]

I cover this in-depth in my higher-kinds series:

https://paullouth.com/higher-kinds-in-c-with-language-ext/

See the section on 'traits'

[ThereIsNoPie]

I've read quite carefully (admittedly my comprehension is poor) but cannot find an answer to my question.

To rephrase my question. When I pull the main branch of language-ext and go to Functor.Trait.cs I see this code:

public interface Functor<F>  
    where F : Functor<F>
{

If I delete the "where" and then rebuild, the entire project still compiles.

public interface Functor<F>  
{

In my mind you've added the "where" for 1 of 2 reasons:

1. There are hidden implications from the c# compiler which make the "where" strictly better.
2. It is a convention so that the Functor definition matches other trait definitions.

Both are legitimate reasons. If the answer is 1 then I would like to know so I can learn more about how c# works under the hood.

[louthy]

Put this into a console project and try removing the constraint:

public interface Monoid<A>
    where A : Monoid<A>
{
    public static abstract A Zero { get; }
    public static abstract A Combine(A lhs, A rhs);

    public static virtual A Combine(IEnumerable<A> items)
    {
        var state = A.Zero;
        foreach (var item in items)
        {
            state = A.Combine(state, item);
        }
        return state;
    }
}

You'll see that the virtual method doesn't compile any more.

By enforcing the implementer of Monoid<A> to be the A itself we make static default behaviours available. Also, it's important that something like Option actually implements the behaviours of Functor<Option> and not some other random type like Functor<Whatever>, we want sensible constraints that stop silly mistakes..

For some traits you could definitely argue this is more convention -- keeping the type in the most constrained state -- ready for any future static default functionality. However, I think it's the right approach, it keeps the types locked down.

I notice that this convention is also followed by the dotnet team with their new traits. Take a look at the interfaces implemented by System.Int32:

  public readonly struct Int32 : 
    IComparable,
    IConvertible,
    ISpanFormattable,
    IFormattable,
    IComparable<int>,
    IEquatable<int>,
    IBinaryInteger<int>,
    IBinaryNumber<int>,
    IBitwiseOperators<int, int, int>,
    INumber<int>,
    IComparisonOperators<int, int, bool>,
    IEqualityOperators<int, int, bool>,
    IModulusOperators<int, int, int>,
    INumberBase<int>,
    IAdditionOperators<int, int, int>,
    IAdditiveIdentity<int, int>,
    IDecrementOperators<int>,
    IDivisionOperators<int, int, int>,
    IIncrementOperators<int>,
    IMultiplicativeIdentity<int, int>,
    IMultiplyOperators<int, int, int>,
    ISpanParsable<int>,
    IParsable<int>,
    ISubtractionOperators<int, int, int>,
    IUnaryPlusOperators<int, int>,
    IUnaryNegationOperators<int, int>,
    IUtf8SpanFormattable,
    IUtf8SpanParsable<int>,
    IShiftOperators<int, int, int>,
    IMinMaxValue<int>,
    ISignedNumber<int>,
    IBinaryIntegerParseAndFormatInfo<int>

Most of those interfaces are new and follow the trait approach. For example, IMultiplicativeIdentity:

  public interface IMultiplicativeIdentity<TSelf, TResult> 
      where TSelf : IMultiplicativeIdentity<TSelf, TResult>?
  {
    static abstract TResult MultiplicativeIdentity { get; }
  }

To a certain extent I do this on autopilot now. For me, this is how traits are done in C#, this is the technique. There are times you can get away with not having the constraint, but it may lead to problems down the track.

[louthy]

Oh, and I think, if I remember right, there's a performance benefit for value-types (avoiding boxing). But don't quote me on that, I've just woken up and my espresso hasn't kicked in yet. It's just something niggling at the back of my mind.

[louthy]

if I remember right, there's a performance benefit for value-types (avoiding boxing).

Just did a bit of IL inspection and I've found nothing to support this, so I don't think there's any performance benefit from adding the 'self'-imposing constraint.

[ThereIsNoPie]

Perfect, thanks for the response, it was exactly what I was looking for.