This project is read-only.


Feature Request / Proposal: Traits


Traits, as "compile-time" partial classes, would perfectly fit with TS ideology and resolve problems of multiple inheritance/mixins.

Traits in Scala:
Traits in PHP:

I propose minimal traits similar to PHP implementation.
trait FooTrait {
   // same as class definition, but no constructor allowed, e.g.:
   public foo() {
       return "foo";
   private bar() {
       return "bar";

class Foo {
    import FooTrait; //not insisting on exact keyword and syntax, just smth to start with

    // ...

class Bar {
    // rename methods:
    import FooTrait(foo => tfoo, bar => tbar);

    // and to include another trait, there is another import line:
    // import BarTrait;

    // ...
The code above could be compiled to JS below (can be optimized, just showing the main idea):
var FooTrait = (function () {
    function FooTrait() {
        throw "Cannot instantiate trait FooTrait";
    } = function () {
        return "foo";
    }; = function () {
        return "bar";
    return FooTrait;

var Foo = (function (_super, FooTrait) {
    function Foo() { } =; =;
    return Foo;
})(undefined, FooTrait);

var Bar = (function (_super, FooTrait) {
    function Bar() { }
    Bar.prototype.tfoo =;
    Bar.prototype.tbar =;
    return Bar;
})(undefined, FooTrait);
Unresolved name conflicts should raise a compile time error.
Closed Jul 28, 2014 at 11:17 PM by jonturner
As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people move them to the GitHub issue tracker for further discussion. Some feature requests may already be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:


SimoneGianni wrote Jun 11, 2013 at 4:46 PM

Details of the implementation may be discussed, but I do second this. I've been using these kind of techniques almost everywhere possible, including languages that are entirely based on non supporting them like Java (using AspectJ) .

It can be implemented in a number of ways. The prototype chain may be altered to include required traits, with proper ordering in respect to the real super class (there is quite some literature on this). Or it could be implemented as simple syntactical sugar with automatic delegation, where the trait is an interface, indicating a "default implementation", and classes using that trait have implicitly defined methods that delegate to an instance of the default implementation.

EisenbergEffect wrote Aug 31, 2013 at 8:43 PM

This would make me cry for joy.

Jaben wrote Oct 15, 2013 at 1:45 PM

+1 I would also like to see this feature added.

yasselavila wrote Jul 9, 2014 at 2:51 AM

Will this be implemented? I think it would be a great advance for the language. But the proposal has more than one year made ​​and has not yet been implemented.

jeffmay wrote Oct 15, 2014 at 9:32 PM

I think this would be a great edition!

I think TypeScript should utilize the flexibility of the prototype system to allow more powerful abstractions than just "interface". It doesn't seem like the JavaScript required to do this wouldn't be too complex.

We shouldn't encourage developers to use the typesystem, only to give them a head ache when they want to mix some implementation with interface in one type. I think TypeScript can and should have a more flexible typesystem than big enterprise languages without having to give up type-safety entirely.

Also, I don't think this would make it harder for JS developers to debug code produced by TSC. If you are debugging this code, you should notice the pattern (and maybe you'll like the pattern and adopt it).