psudo-proposal: Traits/Roles/Shapes/[Your Name Here] + Associated Types + Extension Implementations

[Raein-88]

I'll be using the word trait to refer to this proposal. roles (and the older shapes) are both very closely related to traits but having a distinct name makes discussion easier. Any references to traits in rust will be clarified as such.

As this is a "psudo-proposal" there are gaps and not every single question is answered or discussed. Realistically I doubt this will be adopted as-is, but hopefully some of the ideas/solutions here are helpful anyway.

Tldr

Treating trait/role/shape implementations as members instead of as purely interface implementations allows for a lot of bonus functionality.

Overview

A trait is a package of functionality that relies on a contract. Types can implement a trait by providing an implementation for the trait's contract and by doing so gain access to the "package of functionality" (shortening this to just functionality from now on) of the trait.

A good example of something very trait-like in current C# is IEnumerable<T>. In the terms of traits the contract of IEnumerable<T> is:

• A type that implements IEnumerator<T>
• A method named GetEnumerator that returns the type implementing IEnumerator<T>

The functionality (package) of IEnumerable<T> is the extension methods defined in System.Linq such as Select, Where, and Reverse

(psudo-)Proposal

Definition

A trait is defined much like any other type. They can have the usual access modifiers, be partial, have attributes applied to them, and implement interfaces (More details on that a bit later on). A trait definition will implicitly have a TSelf generic parameter (TSelf is what is usually used for self constraints so I'll stick with that for now). Constraints can be applied to TSelf as needed.

A trait definition also needs the ability to define its contract. Contracts are expressed in terms of members and are very similar to interfaces. A particularly valuable portion of this feature would be contract types, which would be an implementation of associated types.

Functionality members would be the same as defining members in other types. They would be able to access the contract members and use them to implement their features. The this keyword would have the type ref TSelf rather than the type of the trait definition (Need to be careful about potentially allowing reassignment of this for object types, maybe need to tie ability to pass this by ref to a struct constraint on TSelf similarly to ref this extension methods)

Here is a sample of what the definition of a trait could look like.

public trait MyTrait
   where TSelf : //Whatever constraints are needed
{
   public contract int MyProperty { get; }
   //static contracts would be much like static abstract interface members.
   public static contract event Action MyEvent { add; remove; }
   //private modifier would mean that the implementation of this method would not be accessible outside the trait definition.
   private contract void MyMethod();
   
   //A contract type would be treated exactly like another trait definition and allow contract members as well as functionality members
   public contract type MyContractType
   {
       public contract void MyContractTypeMethod();
   }
   //contract types would be in scope for usage throughout the rest of the trait definition. 
   public contract MyContractType GetMyContractType();
   
   //Functionality members
   public void ExampleFunctionality() { }
}

Most of this so far is fairly in line with what other proposals have presented and shouldn't be particularly surprising. There are a few edge cases particularly around contract types that I am glossing over at the moment and saving for further down.

Implementing a trait

Overview / goals

Trait implementations on types are where this proposal starts to differ from other similar proposals. The primary driver for these differences is that usage of traits supports composition-heavy design of types; in the real world there will be cases where a type is implementing dozens of different traits that may very well have overlapping functionality and and contracts. This feature needs to be able to navigate those types of scenarios cleanly. Some of the major goals I kept in mind when putting this portion together were:

• Adding a new trait to an existing type should require minimal changes to existing trait implementations, even if there are overlaps in contract or functionality between the new trait and previous ones.
• Multiple implementations of the same trait should be possible and easy to navigate.
• Diamond "inheritance" and its many cousins need to be dealt with.
• None of the previous goals should interfere with the ability to write clear and concise code for the simpler scenarios.
• It should be possible to define a trait implementation as an extension on an existing type.

Details

Trait implementations are treated similarly to member definitions. They have an access modifier, an identifier, and are marked as either implicit or explicit with a keyword. The functionality of an explicit trait implementation is only visible through the identifier of that implementation. The functionality of an implicit trait implementation will be visible without specifying the identifier (but an implicit implementation must still have an identifier). Any overlaps between the functionality of different implicit trait implementations can be clarified as needed by providing the identifier.

Implementations of the contract for a trait are given in a scope directly below the trait implementation itself, similarly to the syntax for property accessors or the new extension syntax. Once again, here is a hypothetical code sample. (I'll have a more detailed example further down that shows my idea for the less obvious portions of syntax)

public class MyClass
{
    public implicit trait MyTrait Foo
    {
        void MyMethod() { ... }
    }
    
    public implicit trait MyOtherTrait Bar
    {
        bool Value { get { ... } }
    }
    
    private explicit trait MyTrait FooBar
    {
        void MyMethod() { ... } //Some different way of implementing the trait contract
    } 
}

public static class MyClassExtensions
{
    extension(MyClass myclass)
    {
        //would likely be good practice to include extension in the identifiers for an extension trait implementation
        public implicit trait YetAnotherTrait BarFoo_Extension 
        {
            void YetAnotherMethod() { ... }
        }

        public explicit trait MyTrait ImportantThirdOne_Extension
        {
            void MyMethod() { ... }
        }
    }
}

By ensuring all trait implementations for a type (including extensions) have an identifier it becomes possible to navigate even some of the most nightmare fuel scenarios imaginable just by specifying it. Implicit vs explicit also grants direct control over which functionality is visible on your type when you "dot in". Speaking of dotting in...

Using a trait

Functionality from an implicitly implemented trait can be accessed just like any other instance or static members.

Supposing in the code above MyTrait has functionality methods void DoStuff(); and static TSelf Create() (remember, TSelf is the type implementing the trait, so MyClass here) here are some examples of accessing trait functionality.

MyClass val = MyClass.Create(); //usage of the Foo implementation of MyTrait
val.DoStuff(); //Foo implementation of MyTrait
val.Foo.DoStuff(); //Also usage of Foo implementation of MyTrait
val = MyClass.ImportantThirdOne_Extension.Create(); //ImportantThirdOne_Extension implementation of MyTrait

The . operator seems like a natural fit here for explicit trait access. An argument could also be made for using : or another symbol instead to make it more distinct from fields/properties (MyClass:FooBar.Create();) so that may be worth discussing.

Generics

The trick underneath the way generics can work here will be discussed a bit more in the later sections. There are two problems present that generics will need to resolve. First, when constraints produce an overlap in functionality between two traits on the same type parameter the generic method/type will need to be able to qualify between them, but the generic method does not have the identifier. The second problem is how a generic method will know which implementations to use when a type is passed to it.

The second problem is resolved by making generics be generic over the specific implementation of the trait, not the type that is implementing it. This way any ambiguity will be known to the caller and can be resolved by them switching to explicit implementation access syntax and providing the identifier for the implementation they want to pass as a type parameter. Some example syntax for that:

void MyFunction<T>(T value)
    where T : MyTrait
    { ... }
    
class FooBar
{
    implicit trait MyTrait Foo { ... }
    explicit trait MyTrait Bar { ... }
}

//Usage
FooBar value = ...;
MyFunction(value); //No qualify needed. Type inference knows T = FooBar, and the implicit implementation Foo is what is passed.
MyFunction<FooBar>(value); //No qualify needed, uses implicit implementation from Foo.
MyFunction<FooBar.Foo>(value); //Uses Foo with explicit syntax
MyFunction(value.Foo); //Type inference knows T = FooBar.Foo, uses Foo implementation
MyFunction<FooBar.Bar>(value.Foo); //Would need to be an error

Note that the syntax for providing multiple explicit trait qualifications on a single type parameter will need to be a bit more verbose. I'm not sure what that would look like exactly but maybe something similar to tuple syntax? MyFunction<MyType.(Trait1,Trait2)>();? Regardless, this issue only exists in C# syntax, in metadata this problem won't exist.

The first problem also becomes easier to solve with the shift to being generic over specific implementations. We simply can use the type names in the constraints as the identifier because each constraint is being satisfied by a specific implementation individually. Example:

void MyFunction<T>(T value)
    where T : MyTrait, MyOtherTrait
{
    T.MyTrait.DoStuff();
    value.MyTrait.DoMoreStuff();
    T.MyOtherTrait.DoStuff();
}

Practical example

Before I take a one way express train to compiler and metadata magic land and lose most everyone reading this I wanted to give a more concrete example of what it might look like if you wanted to define IEnumerable<T> as a trait, and then provide an extension implementation of it on System.Range to enumerate the values inside the range.

//Enumerable trait definition
public trait Enumerable<T>
{
    public contract Enumerator GetEnumerator();
    public contract type Enumerator
    {
        public contract T Current { get; }
        public contract bool MoveNext();
        public contract void Reset();
        public contract void Dispose();
    }
    
    //Pretend I wrote out all the extension methods on IEnumerable here...
    //Their actual implementations are a bit too much to include
}

//Extension on System.Range
public static class RangeExtensions
{
    extension(Range range)
    {
        public implicit trait Enumerable<System.Index> defaultEnumeration_Extension
        {
            public Enumerator GetEnumerator() => new Enumerator(range);
            public struct Enumerator
            {
                public System.Index Current => this.currentPosition;
                public bool MoveNext()
                {
                    if(this.currentPosition >= this.sourceRange.End) return false;
                    this.currentPosition++;
                    return true;
                }
                public void Reset()
                {
                    this.currentPosition = this.sourceRange.Start - 1;
                }
                public void Dispose() { }
                
                internal Enumerator(Range sourceRange)
                {
                    this.sourceRange = sourceRange;
                    this.currentPosition = sourceRange.Start - 1;
                }
                private readonly System.Range sourceRange;
                private System.Index currentPosition;
            }
        }
    }
}

Low level details

A rough overview of the low level side of this is that a trait definition creates an interface that represents its contract portion and a nested generic struct that has a T constrained by the contract interface. At every site where a trait is implemented on a type a nested type would be defined that satisfies that contract interface, and a property would be defined that returns an instance of that nested struct. Because every implementation of a trait within a type has a unique identifier we can sidestep the problems related to compiler generated nested types.

Metadata

All of this (With one exception that I am unsure on) can be lowered to existing metadata. However, the way it is lowered is somewhat complex and it would be worth considering if there are places that a change to metadata would dramatically simplify things. I'll be omitting some details and focusing on the core shapes of the lowered results.

Trait Definition

trait MyTrait
{
   contract void ContractFunc();
   
   void FunctionalityFunc() { }
}
//Lowers to:
struct MyTrait<TSelf>
{
    interface IContract
    {
        void ContractFunc();
    }
    struct Impl<TImpl>
        where TImpl : IContract
    {
        void FunctionalityFunc() { }
    }
}

Trait Implementation

class MyClass
{
    implicit trait MyTrait Foo
    {
        void ContractFunc() { }
    }
}
//Lowers to:
class MyClass
{
    struct Foo_Impl : MyTrait<MyClass>.IContract
    {
        void ContractFunc() { }
    }
    MyTrait<MyClass>.Impl<Foo_Impl> Foo_Property { get => new(new Foo_Impl(this)); }
}

Usage

MyClass value = ...;
value.FunctionalityFunc();

//Lowers to
MyClass value = ...;
value.Foo_Property.FunctionalityFunc();

Generic definition

void MyFunction<T>(T value)
    where T : MyTrait
{ }
//Lowers to:
void MyFunction<T, TImpl>(MyTrait<T>.Impl<TImpl> value)
    where TImpl : MyTrait<T>.IContract
{ }

Trait definition with contract type

trait MyTrait
{
    contract MyType Create();
    contract type MyType
    {
        contract void MyTypeContractFunc();
        void ContractTypeFunctionality() { }
    }
}
//Lowers to
struct MyTrait<TSelf>
{
    interface IContract<TMyType>
    {
        TMyType Create();
    }
    
    struct Impl<TImpl, TMyType, TMyTypeImpl>
        where TImpl : IContract<TMyType>
        where TMyTypeImpl : MyType<TMyType>.IContract
    { }
    struct MyType<TMyType>
    {
        interface IContract
        {
            void MyTypeContractFunc();
        }
        struct Impl<TImpl>
            where TImpl : IContract
        {
            void ContractTypeFunctionality() { }
            
            static abstract MyTrait<TSelf>.MyType<TMyType>.Impl<TImpl> CreateFrom(TMyType myType);
        }
    }
}

Trait implementation with contract type

class MyClass
{
    implicit trait MyTrait Foo
    {
        class MyType
        {
            void MyTypeContractFunc() { }
        }
        MyType Create() => new MyType();
    }
}
//Lowers to
class MyClass
{
    struct Foo_Impl : MyTrait<MyClass>.IContract<Foo_Impl.MyType>
    {
        Foo_Impl.MyType Create() => new();
        class MyType
        {
            struct MyType_Impl : MyTrait<MyClass>.MyType<MyType>.IContract
            {
                void MyTypeContractFunc() { }
                
                static MyTrait<MyClass>.MyType<MyType>.Impl<MyType_Impl> CreateFrom(MyType myType) => new(myType);
            }
        }
    }
    MyTrait<MyClass>.Impl<Foo_Impl, Foo_Impl.MyType, Foo_Impl.MyType.MyType_Impl> Foo_Property { get => new(new Foo_Impl(this)); }
}

Generic definition with contract types

void MyFunc<T>(T value)
    where T : MyTrait
{
    T.MyType myTypeVariable = value.Create();
    myTypeVariable.ContractTypeFunctionality();
}
//Lowers to
void MyFunc<T, TImpl, TMyType, TMyTypeImpl>(MyTrait<T>.Impl<TImpl, TMyType, TMyTypeImpl> value)
    where TImpl : MyTrait<T>.IContract<TMyType>
    where TMyTypeImpl : MyTrait<T>.MyType<TMyType>.IContract
{
    TMyType myTypeVariable = value.Foo_Property.Create();
    TMyTypeImpl.CreateFrom(myTypeVariable).ContractTypeFunctionality();
}

Generic contract types (Generic Associated Types)

Edit: I spent some time working through this and it is impossible to lower a generic contract type to the current type system so this would end up being reliant on improvements made there.

For reference here is what the hypothetical lowering would need to be.

It

trait CollectionConstructor
{
    contract Collection<T> Construct<T>();
    contract type Collection<T>
    {
        contract Collection<T> Create();
    }
}

class Test
{
    implicit trait CollectionConstructor Foo
    {
        MyList<T> Construct<T>() { }
        class MyList<T>
        {
            static MyList<T> Create() { }
        }
    }
}
//Would lower to something like:
public struct CollectionConstructor<TImplementedBy>
{
    public interface IContract<TCollection>
    {
        TCollection<T> Construct<T>();
    }
    public struct Impl<TImpl, TCollection>
        where TImpl : IContract<TCollection>
    {

    }

    public struct Collection<TCollection, T>
    {
        public interface IContract
        {
            static abstract TCollection<T> Create();
        }

        public struct Impl<TImpl>
            where TImpl : IContract
        {

        }
    }
}

public class Test
{
    public struct Foo : CollectionConstructor<Test>.IContract<MyList<>>
    {
        public MyList<T> Construct<T>() { }

        public class MyList<T>
        {
            public struct Collection : CollectionConstructor<Test>.Collection<MyList<>, T>.IContract
            {
                public static MyList<T> Create() { }
            }
        }
    }
}

Runtime

Ideally we would want some level of runtime enforcement of the TSelf type parameters. Additionally we would want some apis that make it realistic for someone to inspect traits with reflection instead of having them go through the compiler generated types.

An idea to help with the generic type explosion

This isn't very fleshed out and there will be a few issues but I felt like mentioning it. Because we have control over these compiler generated types there isn't anything stopping us from emitting two different versions of it. We could kill many of the generic parameters and use virtual calls through interface types to present the same functionality. As long as the jit is aware of the general pattern it could use the less generic versions initially, but then maybe swap over to the generic versions if it decides to do a tier0 rejit of a method.