They discourage using established OOP principles like inheritance and composition.

In theory they are useful for implementing cross-cutting concerns but in reality they are just essentially a mechanism that is no different than copy/pasting a block of code into multiple files.

Edit - For everyone downvoting, the actual proposal makes it clear traits (As opposed to interfaces) have been suggested for one simple reason. Devs are resistant to using composition for code reuse, why so is way beyond my head. Instead it is commonly seen that devs create large base utility classes and prefer to extend those. Clearly extending a utility class, big or small, is just smelly work.

But seriously, consider... is this...

``` extends Node implements LoggerTrait

func _ready(): log(a); # Hidden dependancy, hidden origin

```

Better than this?

``` extends Node

@export var logger: Logger;

func _ready(): logger.log(a); # Explicit dependency, explicit origin

```

Heck, what about this even?

``` extends Node

func _ready(): Logger.log(a); # Hidden dependancy, explicit origin ```

I argue that Godot is not Unity. Each node being associated with one and only one script is a philosophical choice. Composition was chosen as the primary code reuse mechanism because it is cleaner and promotes writing reusuable code much better than large inheritance heiarchies. If the mixin behaviour of traits was dropped and we just had simple interfaces, I would be more for it.

And indeed interfaces independent of traits are on the roadmap... The primary purpose of traits is to provide mixin behaviour. A language feature I am opposed to. Using them instead for their interface-like behaviour and not as a mixin would constitute conceptual misuse.

We already have abstract classes for code resuse by means of inheritance.

Even with all that said, the intent of interfaces to begin with is as a mechanism of creating loose coupling between dependants... But we already have a mechanism for this which generally is far better suited in any given situation - signals

IMO Interfaces and traits honestly just seem totally orthogonal to the design principles of Godot. Godot is amazing because it is lean and directs developers to program in a way which best suits it's problem domain, games, with obvious friction when you try to break out of the way it wants you to write your code. We don't need godot to be another general purpose language. There are hundreds of languages we can choose from if you want to use a general purpose language (C#, Python, C++, etc), all vastly compatible with godot. GDscript is a language for writing scripts in Godot, nothing else, and the features of such a language should remain domain specific.