It looks like duck typing to me.

Seems to me something like a combination of traits, contracts.

It looks like duck typing to me.

Quack.

It's an interesting idea, but I think you left out something important in your proposal: this would only be useful as a generic constraint.

For instance, a template that would enforce the presence of an addition operator:

public template Addable<T>
{
    public static T operator +(T x, T y);
}

Could be used like this:

public static T Sum<T>(this IEnumerable<T> source)
    where T : Addable<T>
{
    return source.Aggregate((x, y) => x + y);
}

"It can require that certain protected or internal members be present."

What use is this? It seems like what an abstract type would do.

It is not clear from this proposal what context trait names could be used in the language.

Is it possible that some of the proposed features for Class Templates be implemented by the suggested enhancements to Interfaces? For instance, allowing Interfaces to declare Static Methods, Static Properties and Operator Overloads?

I think that will generally keep things cleaner and not necessarily complicate the language. If I remember correctly, one of the Anders' mantras was to introduce new keywords in a language only as a last resort.

However making interfaces support Statics will require updates to the CLR and many BCL classes. I see that as a good thing because it will enrich the entire CLR infrastructure (other languages benefit) without introducing too many moving parts and "concepts" that programmers have to learn afresh.

Ultimately, the proposed benefits behind traits, mixins, and templates can get rolled up into one, if the implementation is done right. It will feel more like a natural/organic progression...

@gafter I think that would be just (static?) methods, since these "template" types should be resolved at compile-time (pretty much like inline functions in F# and compile-time resolved generics e.g. ^T).

Just a vote for offering the possibility under the hood to inline code and devirtualize calls using the actual types (i.e. Template<A> and Template<B> generates separate optimized machine code), just like C++ would do.

This is one of the big use case of template in C++ (it generates tight optimized code, and you can even transfer functors -- but this one might be harder).

So, if I understand correctly, any delegate with the signature of void -> void like Action matches the following template/trait/structural type,

trait ActionTrait {
    void Invoke();
}

@alrz yes, but only if traits are applicable to delegates as well.

@orthoxerox As long as delegates translate to a special but yet, classes, we would have it for "free". Still, I think these so-called "traits" should be resolved at compile-time just like F#'s inline functions and member constraints, because compiler should know exactly what members are in question. This probably lessens portability of traits as proposed in this thread (implicitly implementing interfaces doesn't seem to work really, as discussed in the duplicated thread #7844 as well); likewise, you can't declare "inline methods" for classes in F#. As mentioned in #420, this needs CLR support; but as a consequence we would have "structurally equivalent delegates through traits" which I think brings a lot of value.

I tried to write my own very rough vision of how a trait/template should work:

Definitions

A trait is a new construct in C# language that can be used as a generic parameter type restriction.

A trait has a visibility modifier. Traits can be either public or internal.

A trait has a name. Trait names should begin with an uppercase "T".

A trait can inherit from other traits.

A trait contains declarations of operations.

Declarations of operations must have:

• a return type
• a name
• a parameter list
• an optional default implementation in terms of other operations of this trait or its parent traits. Implementations can be mutually recursive.

Operations can use the trait name as a type in either the return type or the parameter list. It is understood to be not an instance of any conforming type, but an instance of the type matching the restriction.

Two operations are in conflict if they have the same name and the same types of the parameter list.

It is an error to define two operations that are in conflict in a single trait.

When a trait inherits from different traits operations that come in conflict, they either must be explicitly merged or at least one of them must be renamed. It is an error to merge traits that both have default implementations.

It is allowed to define an operation that is in conflict with an operation defined in a parent trait if the new operation has an implementation and is marked with a new keyword. Such operation can shadow two or more operations that would otherwise have been in conflict.

Classes, interfaces and structs can conform to traits. To conform to a trait a class/struct/interface has to provide (potentially abstract) implementations of all operations defined in the trait and its parents. The implementations do not have to be members of the conforming type, but they must be visible to the trait.

A field, a constant can serve as an implementation of a non-void operation with an empty parameter list.
A property of type T can serve as an implementation of:
- a non-void operation with an empty parameter list if it has a getter;
- a void operation with a parameter list of length 1 if it has a setter.

An indexer property of type T with N indices can serve as in implementation of:
- a non-void operation with a parameter list of length N if it has a getter;
- a void operation with a parameter list of length N+1 if it has a setter.

A static method can serve as an implementation of an operation with the same return type and parameter types.

An instance method can serve as an implementation of an operation with the same return type and parameter types as its open delegate.

A constructor of type T with N parameters can serve as an implementation of an operation with return type T and N parameters with the same types.

Implementations must be explicitly mapped to the operations. When they have the same name, the mapping can be omitted. It is allowed to not map implementations to operations if operations have default implementations defined in terms of defined implementations.

Already defined classes or structs can be declared to conform to traits. This is done via a partial definition that doesn't contain a body. If all necessary operations can be mapped to implementations implicitly, this is not required.

Traits cannot have generic parameters 😢 until HKTs are implemented in the CLR.

Traits and operations cannot have attributes (a temporary measure, I would love to mark and enforce transitivity, identity, closure and other properties of relations and operations).

Some syntax examples

public trait TEquatable
{
    bool operator ==(TEquatable lhs, TEquatable rhs) => !(lhs!=rhs);
    bool operator !=(TEquatable lhs, TEquatable rhs) => !(lhs==rhs);
}

public partial struct double
    : TEquatable
        {
            operator == is Equals;
            // operator != is defined in terms of ==
        }
{ }

public class Foo
    //: TEquatable //It's not necessary, but possible to declare that Foo conforms to TEquatable
{
    ...

    public static bool operator ==(Foo left, Foo right) => ... ;

    ...
}

public trait TAddable //Monoid
{
    TAddable Zero();
    TAddable operator +(TAddable lhs, TAddable rhs);
}

public trait TSubtractable //Group
    : TAddable
{
    TAddable operator -(TSubtractable rhs);
    TAddable operator -(TSubtractable lhs, TSubtractable rhs) => lhs + -rhs;
}

public partial interface IEnumerable<T>
    : TAddable
    {
        operator + is System.Linq.Enumerable.Concat;
        Zero is System.Linq.Enumerable.Empty
    }
{}

//Traits are not virtual, so this will be used only if you actually pass a value of type ImmutableList<T> to the function.
public partial class ImmutableList<T>
    : TAddable
    {
        operator + is AddRange;
        Zero is Empty;
    }
{}

public const int IntZero = 0;

public partial struct int
    : TAddable
    {
        Zero is IntZero;
    }
{ }

//And now we can actually get rid of the numerous System.Linq.Enumerable.Average overloads.
public trait TAverageable : TAddable
{
    TAverageable operator /(TAverageable lhs, int ths);
}

public struct Point3<T>
    : TAverageable
    {
        Zero is Origin;
    }
    where T : TAverageable
{
    public T X { get; }
    public T Y { get; }
    public T Z { get; }

    public static readonly Origin = new Point3(T.Zero(), T.Zero(), T.Zero());

    public Point3(T x, T y, T z)
    {
        X = x; Y = y, Z = z
    }

    public static Point3<T> operator + (Point3<T> lhs, Point3<T> rhs)
        => new Point3(lhs.X + rhs.X, lhs.Y + rhs.Y, lhs.Z + rhs.Z);

    public static Point3<T> operator - (Point3<T> lhs, Point3<T> rhs)
        => new Point3(lhs.X + rhs.X, lhs.Y + rhs.Y, lhs.Z + rhs.Z);

    public static Point3<T> operator / (Point3<T> lhs, int rhs)
        => new Point3(lhs.X / rhs, lhs.Y / rhs, lhs.Z / rhs);
}

public partial struct double 
    : TAverageable {
        Zero is 0.0; //Why not allow literals as well?
    }
{ }

public partial struct float 
    : TAverageable {
        Zero is 0.0f; //Why not allow literals as well?
    }
{ }

//Now we don't have to define neither Point3F nor Point3D, 
//and both IEnumerable<Point3<double>> and IEnumerable<Point3<float>>
//can be passed to our generic Average<T>() function:

public static T Average<T>(this IEnumerable<T> source)
    : where T : TAverageable
{
    T sum = T.Zero();
    int count = 0;

    foreach (var item in source) {
        count++;
        sum+=item;
    }

    if (count>0)
        return sum/count;
    else
        throw new Exception();
}

@orthoxerox (1) The nice thing about extension methods is that they can be defined on generic parameters, I think traits should be able to be implemented on a generic parameter as well. (2) Your TEquatable should be generic actually and it doesn't really add much other than duplicating and delegating operators for each type. (3) Since your operators are getting two parameters actually they are static and should be declare as such. (4) I really couldn't understand derived or Zero is IntZero syntax. The TAverageable declaration is even circular! Don't know how I supposed to look at it.

Anyway, I really liked Rust syntax for traits and it is very powerful btw. For example, utilizing #7671:

trait TEquatable<T> {
    static bool operator ==(T lhs, T rhs) => !(lhs!=rhs);
    static bool operator !=(T lhs, T rhs) => !(lhs==rhs);
}

implement <T : IEquatable<T>> TEquatable<T> for T {
    static bool operator ==(T self, T other) => self.Equals(other);
}

This would allow to implement TEquatable<T> for all types that already implemented IEquatable<T>. You can look at it like a group of extension members (#6136) implemented for a type (for) as a type (trait).

Traits as being discussed here are very similar to interfaces with static members (#2204), operators (#5624) and default methods (#258) plus a pluggable implementation (#3357). I wonder if these all could be merged together.

What should happen in the following case? where at least possible methods are applicable.

,,, Foo<T : IComparable<T>)( ... )
... Foo<T : TComparable<T>)( ... )

Does the trait have an higher precedence?

@AdamSpeight2008 see #7459 for an answer.

I have updated my draft to include the possibility of operations being mapped by name implicitly and fully implicit trait implementation.

@orthoxerox I think you don't need a trait just for average. As far as I can tell, it would be something like this,

interface IZero<T> { static T Zero { get; } }
interface IAdd<T, U, V> { V operator+(T, U); }
// etc

U Average<T, U>(IEnumerable<T> source)
    where U : IZero<U>, IDiv<U,int,U>
    where T : IAdd<U,T,U>
 {
    var sum = U.Zero;
    var count = 0;
    foreach(var item in source) {
        count++;
        sum += item;
    }
    return count > 0 ? sum / count : throw new Exception();
 }

Note that I'm using interfaces assuming that they can be plugged to other types like #3357. Also check out Rust's trait abstractions for primitives, in addition, it has default generic parameters (#6248), self type (#311) and associated types (no issue) which greatly help with the abstraction you had in mind.

@alrz That requires the Type of explicitly implement those interfaces.

@AdamSpeight2008 So these traits would be just compile-time constraints, right?

@alrz
For me personnally they should be yes. Unless you explicitly specify the restriction dynamic (which would involve a runtime check). eg < T : {trait, dynamic} > a little something akin TypeScript

@AdamSpeight2008 In that case, the whole method should get inlined, right? For example,

class A { int P { get; } }
class B { int P { get; } }
trait T { int P { get; } }
int F<X>(X arg) where X : T => arg.P;

In the last line there is no way for compiler to know what property should be emitted, unless in every call it get inlined with the client type.

It will know cos it going to be called on something. eg F(new A) or F(New B)
F(new object) won't compile.

@alrz Yes, if we add pluggable interfaces with static and non-virtual methods the interfaces become a lot like the traits I had in mind. The only remaining differences are:

1. traits allow you to rename your type members (can be added to regular inheritance as well)
2. traits are optimized away at compile time, you are not going through an interface, you are calling specific methods or accessing specific properties of the type itself, that's what allows you to treat constructors and fields as methods, for example.
3. traits are not types, you can have a list of IAddables, but not a list of TAddables.

Just to chime in with another example of trait usage, here's one I've thought about before that has corollaries in Rust and Haskell:

trait TParsable<T>
{
    T Parse(string s);
    bool TryParse(string s, out T);
}

static class StringExtensions
{
    public T Parse<T>(this string s) where T : TParsable<T>
    {
        return T.Parse(s);
    }
}

This would let you write very simple parse code such as "1".Parse<int>() while requiring that the type you specify to be parsed is parsable (e.g. "1".Parse<HttpClient>() would not compile). It also lets you write generic methods for any parsable type.

Haven't seen this mentioned in this issue, but there's been some concrete work done on something very similar to this at the CaptainHayashi/roslyn fork. I've been going through the doc and it looks pretty amazing; seems like it would solve a whole slew of open issues all at once. I don't know if there is an issue dedicated to it though, or what the language design group's opinions on it are.

It reminds me concepts in C++17 only there it's done as part of templates instead of introducing another concept to the language.

p.s. I really like the idea. :)

@masaeedu the issue with their approach is that it doesn't support generic types well. Their proposed changes to type inference might help, but getting direct support for HKTs in the CLR would be even better.

@eyalsk You've got the jist of the idea.