Proposal: Reduce boilerplate by allowing fields in interfaces aka "traits"

[SmikeSix]

Hi I did rewrite this, and renamed contracts into traits since I think its the better naming.

The reason for a trait-like system is code organization, which is poorly reflected in object-oriented practices and often leads to bloated, cross-referencing code that is hard to maintain and has poor performance characteristics.

A trait-like system would work as a local slice or organizational pattern for related, optional systems.
Inheritance organizes code vertically through ancestry. Traits do the same horizontally, by sharing capabilities across unrelated types. Traits are the missing horizontal dimension needed for truly clean and compositional OOP.

Usually, when you want to have objects with certain shared behaviours, you have three options (excluding factory patterns and focusing on raw language features):

1. Create a base class that all related objects must inherit from.
2. Create a standalone instance of a class that is held as a local reference.
3. Use an interface for the object that exposes only methods.

You can write software this way, but it often ends up becoming an entangled mess of indirections and deep layers of nested complexity.

• The interface leads to objects sharing data that is indirectly accessible, increasing the time it takes to find and work with code.
• The standalone instances lead to objects holding other objects, and if you are doing performance work, you also need to handle their lifetimes and pooling. Leading to constant cross object referencing.
• Inheritance works only as long as the objects are of the same fundamental type. But it is hierarchical, and you often find yourself asking, "How do I fit this new behavior in now?" Then you are back at using standalone instances.

Traits, as stateless, non-instantiable interface-like structures that let you define required fields, would solve this issue with object-oriented languages.

Positive effects on code design would be:

• Unifying behaviours between different types of objects.
• Reducing the need for standalone instances.
• Lowering code complexity and navigation time in large codebases.
• Potentially better performance (though debatable).
• Test Isolation of "traits"
• No need for the partial class mess. (Oh this.. needs to hold popup chain data because.. ok lets put it in here and call it partial?)
• Faster & easier refactoring. You refactor the trait.
• Easy extensions of existing types

Like call me crazy, but traits would be a wonderful addition to C# solving a lot of problems that exist in large code bases.

public trait TRotatable
{
    public Quaternion rotation;

    public void Rotate(Vector3 axis, float angle)
    {
        rotation *= Quaternion.CreateFromAxisAngle(axis, angle);
    }

    public void LookAt(Vector3 targetPosition, Vector3 myPosition, Vector3 upDirection)
    {
        Matrix4x4 lookAtMatrix = Matrix4x4.CreateLookAt(myPosition, targetPosition, upDirection);
        rotation = Quaternion.CreateFromRotationMatrix(lookAtMatrix);
    }
    
    void MustBeImplemented(); //this must be implemented like an interface
}

public class Ball : TRotatable //Ball receives its fields from its trait. 
{ 
    public Vector3 position;
    
    //default implementations can be added and overwritten with getter / setter
    public Quaternion rotation { get; set; };

    public void PrintPositionAndRotation(){
    print(position + " " + rotation);
    }
}

public class PlayerCamera : TRotatable //PlayerCamera receives its fields from its trait. 
{ 
}

public trait TMovable { Vector3 position; }
public trait TRenderable { Vector2 position; } // Different type! compiler error

public class Entity : TMovable, TRenderable { } 

Lifetime Managment:
Traits and their auto field definitions are part of the object that holds them, so default values, can be written like this:

public trait TRotatable
{
    Quaternion rotation = Quaternion.Identity;
}

public class Ball : TRotatable
{
    public Vector3 position;
}

Constructors:

public trait TRotatable
{
    Quaternion rotation = Quaternion.Identity;
    
    // Trait constructor - defines how to initialize trait fields
    public TRotatable(Quaternion initialRotation)
    {
        rotation = initialRotation;
    }
}

public class Ball : TRotatable
{
    public Vector3 position;
    
    public Ball(Vector3 startPosition) 
    {
        // Compiler injects trait initialization first if default is given
        // this.rotation = Quaternion.Identity;
        position = startPosition;
    }
    public Ball(Vector3 startPosition, Quaternion rotation) : TRotatable(rotation) //
    {
        position = startPosition;
    }
}

public trait TPhysical  
{
    float mass;
    public TPhysical(float m) { mass = m; }
}

public class PhysicsBall : TRotatable, TPhysical
{
    public Ball(Vector3 pos, Quaternion rot, float mass) 
        : TRotatable(rot), TPhysical(mass)  // Multiple trait constructors
    {
        position = pos;
    }
}

Generics:

public trait TRepository<T>
{
    T GetById(int id);
    void Save(T entity);
}

public class UserRepository : TRepository<User>
{
    public User GetById(int id) { ... }
    public void Save(User entity) { ... }
}

Reflection:

var ball = new Ball();
var traits = ball.GetType().GetTraits(); // [TRotatable, TPhysical]
var hasTrait = ball is TRotatable;       // true or we could use ball has TRotatable... is probably fine:
if (ball is TRotatable rotatable)
{
    rotatable.Rotate(...);
}

There are quite some other points like static fields, trait inheritance and if they can implement interfaces (prob yes to interface + statics). That are still missing, but they could be a powerful addition to C#. The examples here are just small code bases, the real value would come when you implement things that are larger. Like a TPopupWindowManager or anything like it.

One major issue is trait inheritance, since it would recreate problems that OOP recreates. The remaining question, that maybe even breaks this whole system is:

Is trait inheritance worth the complexity? Or should traits remain flat, composable units that avoid hierarchical thinking entirely?

This is a large question for such a proposal. If they stay flat, then we are potentially back to standalone instances. If they are hierarchical it opens another can of worms. This would need to be tested when writing code within such a system and if the complexity they would add to C# is worth their functionality. They may be better off to be a functional flat part of C#, offering component based functionality without inheritance. So instead of:

GameObject → Entity → Character → Player

you get:

Player : TMovable, TRenderable, TPhysical, TControllable

screams in java xD

And yes you are close to this point with interfaces, but traits would just offer an additional code organization pattern, they keep the rest as is. And just allow better code organization & separation of concerns.

The diamond inheritance problem is no problem, since a trait works like an interface and is stateless, double definitions merge. So having two traits that require the same fields, is the same as having two interfaces that offer the same method.

Ok back to coding, those interfaces aren't going to implement themselves... unfortunately^^

[huoyaoyuan]

#8075. It's just composing, and will immediately meet the famous diamond inheritance issue.

[SmikeSix]

A new language feature will require someone else writing a lot more code than an SG, not to mention all the design meetings and documentation.

Plus, it will take at least a year, and that's if it was immediately accepted into the language for C#15. If not, add another year at least.
"interfaces, but lazy"
Haha you got it! Yes lazy! Less code to write, separation of concerns. Single source of truth, with opt in complexity. Less distributed data hiding behind interfaces. One contract to bind them all.

And yes you could do some source code generation. But.. that does not solve it, where it is needed. In high performance enviourments or in data driven development paradigms, where compile times matter. This should be part of C# as a language.

An interface with an getter / setter implementation, does it kinda. Just in worse, adding unnecessary complexity.

--

And just to counter the source code gen argument.. like don´t get me wrong. Yes you can source code gen a lot of stuff.. but its a bit of a deflection.

Public forum for feature proposals: "Hey what about feature X" -> "How about you do it yourself? Do you know its a lot of work". No beef, I can understand people may not like it.

But what I want to discuss are the merits in terms of data structures, ease of development and the options such a feature could offer. And what the negatives and or positives are.
I´m writing a lot of performance data driven code in C#, and also a lot of UI framework stuff. And it would make maintaining large codebases & refactoring & planning easier. And I believe it should be a core feature of C#.

[HaloFour]

The reality is that such a proposal is never going to be added to the language, so your only option is source generators, T4 or some other kind of code generation. Source generators were added as an officially supported part of the C# compiler specifically to solve these kinds of requests, where someone in the community can solve the problem for themselves with a nominal amount of effort.

[SmikeSix]

I'm not saying I need this, id say C# would be a better language if it had that - and I want to discuss it.
Its a feature for large codebases with high levels of dependencies and source code generators do not solve that.

If your only argument in a feature purpose thread is that it can be somewhat solved by doing source code generation, so do it yourself. Then just say it like that and not go the passive aggressive boilerplate route^^ haha gotcha

[spydacarnage]

I can't see how C# would be better by adding a new type that is basically the same as an interface but with laziness built in.

When a feature makes one person's individual code style better, that is a perfect use of a source generator. I've done it myself in enterprise-level, high-throughput code.

In order to get something like this into the language, you'd need to be able to prove an actual benefit to a vast swathe of the user base, and the first two people to read it aren't convinced.

[SmikeSix]

its not only about code style, but data centric behaviours. and yes that's what I wanted to discuss^^
I did use source code generators in game dev to avoid deserialization of data, baking it into the code itself. similar how jai does it.

I think its an game dev centric topic, where data driven, low hierarchy code with low levels of abstractions are needed. if you have to navigate through 5 methods to find something hidden behind 3 interfaces, shared by 3 classes, in a stack trace 20 layers deep .. to find your data its just normalized enterprise insanity. and I'm not saying its always bad, but the current system encourages bad practices and unmaintainable code.

right click go to implementation -> there is one default, shared by classes. it gives you a vertical slice of your classes / data

[spydacarnage]

Are you wanting to pass these instances of these contracts around, like interfaces?

i.e.

public void DoSomething(cEditorContext ctx)
{
    ctx.markVirtualizationAsDirty = true;
}

Because, if not, you can write a source generator that adds the default members to any class marked with an appropriate attribute. It can be written to not add a specific member if the user-code already defines one.

[SmikeSix]

They would work like interfaces in that case, so yes, you hand them around.
It's basically an interface with a more direct data-binding approach. Its aim is to reduce friction when designing large, OOP-oriented structures, while making refactoring of codebases trivial.

[martin-steinhoefer]

Traits, as stateless, non-instantiable interface-like structures that let you define required fields, ...

Isn't defining traits to be state-less at one side and requesting fields for them on the other side a contradiction in itself? Do I miss something?

[SmikeSix]

hey it depends on what a language would do with it. my suggestion was that you put the mark-up for the field into the trait itself. like one definition, one place as default. its like having a default interface, that just does its thing. lazy interfaces someone called it, which id also take.

you can not instantiate a trait.

public trait TMovable { Vector3 position; }
public trait TPhysical { float mass; }
public trait TRotatable { Quaternion rotation; }

public trait TMovable { Vector3 position; }
public trait TPhysical { float mass; }
public trait TRotatable { Quaternion rotation; }


public class Ball : TMovable, TPhysical, TRotatable { 
//Vector3 position; 
//float mass;
//Quaternion rotation; are actually living in the class
}

Its an organizational pattern, that lets you extend code into the horizontal, and build component based systems. It does not replace object oriented programming, it is just another pattern in a toolbox to design software and to organize structures. What inheritance does in the vertical, traits would do in the horizontal.

It basically moves C# a bit more towards a more C like code patterns and helping with those deeply nested, abstracted away code patterns you find everywhere. OOP just ends up producing code that uses.. natural obfuscation as a design principle

[martin-steinhoefer]

Do I understand you correctly, that the fields in your traits aren't fields, but abstract place-holders? Such, that a class inheriting (or implementing) a trait somehow provides them?

Actual trait implementations do something far more flexible. They require the supporting type to provide some members to provide with state access - just not fields. It's possible to have functions returning values and methods accepting state - without actually exposing how state is implemented; without forcing the implementing class to an actual representation of state (any implementation that supports the contract is as good as any other) - to me that is a huge benefit.
Actual interface definitions in C# allow for exactly that

• abstract members can be protected - forcing state to be encapsulated
• having default members - providing implementations based on "state providing members" without the need to actually enforce an implementation of state
• multiple "inheritance"

If that is what your trait idea is, I don't get, why do we need a new syntax? What is the benefit? ...nobody needs a field place-holder. One can always go for an abstract property (perhaps protected). The class implementing the interface has to provide an implementation of them... ...so we already have everything needed? (maybe except for renaming of trait members - but you didn't seem to miss that)

btw: Adhering to OOP does not automatically lead to deep inheritance hierarchies. One always can favor composition (or association) over inheritance and use interfaces to "flatten" the hierarchies. If deep hierarchies are a problem, then perhaps the used libraries are not optimal. But that is no problem of C# in special nor of OOP in general.

[SmikeSix]

yes id rather have this happening in interfaces. I called it traits because I could see people being against it, since I want to move the default field implementations into the interface. Id like the default to be in one place. 80% of time you just reimplement interfaces with the same stuff over and over again and park the same fields everywhere. Then you handle yourself through the getters and setters.

My point of view is not a necessarily a "pure" OOP one, but a purely practical one. If it reduces the amount of code I have to read / write, and the times I have to click into something is reduced. Then that is good design.

Interfaces as they are right now, obfuscate the navigation and hide the execution path of code. You have the requirements of the interface to deliver data and methods anyway. Just let the implementation overwrite the default field with a getter/setter if they want to. And make the common case the default.

As soon as you introduce a interface, you walk an extra click or two. The common case is, everyone uses the same fields, the same methods, the same implementation anyway. And right now your logical flow does this obj ->interface -> obj -> interface -> obj -> interface dance, for no reason at all ^^

I mean I get it, but after decades I'm just like nah f*** this its the wrong way around. Like you walk with your hands and call the sky your floor.

You could call it

public default interface.
int myField;

and if you implementation wants to overwrite it you can do ->
int myField get set;

the others get a public int myField field hahah. I mean in the end it really doesn't matter, besides that we were told its bad. But its not. The bad thing is two extra clicks and poorer navigation in code bases.

[martin-steinhoefer]

I still don't see the actual benefit of your proposal...

[spydacarnage]

I think the other problem here is that you want these interfaces to define fields, which they do not - fields are meant to be behind-closed-doors implementation details, not part of the public surface area.

And then you want to an implementing class to be able to override a public field with a public property of the same name.

So, when passing around an instance of your IPhysical, how is the callsite meant to know if mass is a field or a get_mass() method?

So, while you previously refuted that this was a way to make your coding style easier, that's exactly what this is - a deliberate departure from the C# paradigm, and not one that I, for one, can support.

[TahirAhmadov]

#5897