[Proposal] Add support for traits and/or mixins

[dsaf]

Description:

http://en.wikipedia.org/wiki/Trait_%28computer_programming%29

Previous discussions:

https://roslyn.codeplex.com/discussions/570952
https://roslyn.codeplex.com/discussions/542646

[gafter]

@dsaf As far as I can tell #129 has nothing to do with this. #129 is about constraints, and this is about behavioral inheritance.

[dsaf]

@gafter you are right.

[AdamSpeight2008]

@gafter @dsaf

#129 isn't about constraints. It's about creating an abstraction for a common set of proposals and existing features. All of which focus around does this (whatever this is interface, contract, constraint, generic type, static method) met some specific criteria.

Which can be interpreted as concrete implementations of some sub type of trait validation.

 Interface <: Trait 
Static Interface <: Trait 
Generic Constraint <: Trait 
Non - Null <: Trait

It is different to an interface, since it doesn't require it to a baked into the object being validated.
For example does this object have a specific method? Not necessary indicated via an interface.

Complements Generic Constraints, and extends it feature, as well as they can be extracted out into a library, and allow us to inheritance in their definition.

[gafter]

@AdamSpeight2008 Sure, if you like the word criteria bettern than constraints. In either case #129 isn't what computer scientists call traits, and it would be less confusing if you select a different word.

[AqlaSolutions]

It's a great duplication reducer. There are some usecase examples in #4980. I would really like to see this feature in C#.

[alrz]

@dsaf This is about traits or mixins? Perhaps you should change the title to be more specific. I'm thinking that this thread is considered for proper mixins.

[dsaf]

@alrz I don't have enough experience with both to make a judgement. Are these concepts really that clearly defined? E.g. how different is a stateful trait from a mixin?

[alrz]

@dsaf Mixins are about behavioural inheritance, while traits are similar to interfaces, for example in Scala interfaces are presented as traits, that close. But I don't think that it has anything to do with mixins.

[dsaf]

@alrz What about this:

http://docs.scala-lang.org/tutorials/tour/mixin-class-composition.html

To define a class that can be used as a mixin we use the keyword trait

http://docs.scala-lang.org/tutorials/tour/traits

Traits are typically integrated into a class (or other traits) with a mixin class composition

[alrz]

@dsaf Well, in these definitions, a trait is considered as a target for a mixin composition. Still it doesn't change the meaning of a trait. And since in C# there is no trait, I expect class instances can be composed to other classes as interface implementations through mixins. Still, everything has its own definition.

[GeirGrusom]

Mixins can have state whereas traits can't. Java 8's default methods is a trait implementation.

[dsaf]

@GeirGrusom what about so called "stateful traits" that actually can have state?

[GeirGrusom]

Why would something that describes a trait of some object require state? If it can't rely on the objects state it's not really a trait of that type; it's a mixin.

[dsaf]

That's a question for computer scientists / language designers I am afraid:

http://stephane.ducasse.free.fr/Presentations/2009-TraitsAtSC.pdf

http://soft.vub.ac.be/Publications/2009/vub-prog-tr-09-04.pdf

[alrz]

Since I've got the habit of implementing anything with generators, so,

partial class Class {
  [Mixin] ISomething something = new Something();
}

// to be generated
partial class Class : ISomething {
  public void DoSomething() => something.DoSomething();
}

Not sure what exact capabilities are discussed in the original post though.

[axel-habermaier]

@alrz: Nice one! Seems like generators could be the most important feature of C# 7, even more so than pattern matching. Particularly since records and discriminated unions won't make it.

[dsaf]

The proposal is not specific because I am not qualified to describe it properly. It's mostly to register an interest towards this language feature.
I am not surprised that code generation can be used to "implement" custom language features, especially when language/compiler gives additional support for it. E.g.
https://bitbucket.org/skwasiborski/mixins/wiki/Home , http://joseoncode.com/2011/02/01/static-mixins-in-net

Still not a fan of partial types.

[alrz]

Still not a fan of partial types.

@dsaf If you are referring to the source type being partial see #6953, otherwise, I don't see what is wrong with partial types, considering that they are actually the very feature that make generators useful in the first place.

[UnoSD]

Subscribing to the discussion. @UnoSD

[MartinJohns]

Hey @UnoSD ,

Just a friendly pointer that there is a subscribe button to subscribe to discussions. No need to add pointless comments. :-)

It's on the right side:

[UnoSD]

@MartinJohns, unfortunately if you subscribe just with the button, then you won't be able to search for the issues to which you are subscribed. In this way, you can also search for mentions, that's just a small workaround until finally the GitHub team implements a solution: isaacs/github#283

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.

Traits are now proposed at dotnet/csharplang#52 and are under active design/development.