Wouldn't it be more correct to bind all member functions by default? I think it makes more sense to specify the type of 'this' when it is not going to be the class that the function is defined in. So a syntax more like C#'s 'extension methods' make more sense:

class Foo {
public static someUnboundMethod( this : OtherClass ): void {

    // this would be of type OtherClass and invalid to be called from 'this.' context

}
}

This completely breaks JavaScript own vs inherited property semantics:

var Foo = (function () {

function Foo() {
    this.someMethod = this.someMethod.bind(this);
}
Foo.prototype.someMethod = function () {
};
return Foo;

})();

I'm using this approach only for event handlers. This is very handy to bind handler to current instance, if you later want to unbind it.
Using lambda expression you can't unbind handler easily, you need to add a reference for created function.

Here are example. I have a class with mouse click handler and I want unbind it during first call.
I found 3 way to make it:

1. Add reference to lambda so you can remove event listener later:
   

class Foo {

private lambdaFunc: EventListener;

constructor () {
    this.lambdaFunc= (e) => { this.clickHandler();};
    document.addEventListener('click', this.lambdaFunc);
}

private clickHandler() {
    document.removeEventListener('click', this.lambdaFunc);
    alert('Hi');
}

}
new Foo();

1. Add reference to binded method:
   

class Foo {

private bindClickHandler: EventListener;

constructor () {
    this.bindClickHandler = this.clickHandler.bind(this);
    document.addEventListener('click', this.bindClickHandler);
}

private clickHandler() {
    document.removeEventListener('click', this.bindClickHandler);
    alert('Hi');
}

}
new Foo();

1. Bind method in constructor:
   

class Foo {

constructor () {
    this.clickHandler = this.clickHandler.bind(this);
    document.addEventListener('click', this.clickHandler);
}

private clickHandler() {
    document.removeEventListener('click', this.clickHandler);
    alert('Hi');
}

}
new Foo();



I like the last one. But you can do it even better: make bind keyword so you can use it like this

constructor () {

document.addEventListener('click', this.clickHandler);

}

private bind clickHandler() {

document.removeEventListener('click', this.clickHandler);
alert('Hi');

}

I think @joewood72 has a point. I would assume that especially in a class this always refers to the right context. So I would make bind-the-current-context the default behavior as well.

I think @joewood72 has a point. I would assume, especially in a class, that this always refers to the right context. So I would make bind-the-current-context the default behavior for instance methods as well.

I understand the desire to see TypeScript offer further help here. However, we consider it very important to maintain JavaScript runtime semantics and to allow interoperation with existing JavaScript coding/usage patterns. ES6 classes will not do any bind-on-extract, and so TypeScript cannot do this implicitly either.

We may be able to add warnings/errors on attempts to extract a method off a class instance. This would at least bring attention to cases where this bug might occur.

I'm also supportive of the "bind operator" proposal from Dave Herman, though I think it could be modified to offer even simpler syntax for bind that fits the most common use case of method extraction:

http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator

I expect we will look at both the warning and the bind operator as options for TypeScript.

we consider it very important to maintain JavaScript runtime semantics and to allow interoperation with existing JavaScript coding/usage patterns

If so, then why force adding the "this" keyword to every class-member usage, as opposed to JS automatic inference?

We have the following situation:

1. "this" doesn't add any useful information in determining the execution context; The meaning of "this" can be changed arbitrarily by an external caller.
2. "this" in syntactically enforced as opposed to JS.
   

Either make "this" useful, or don't require its inclusion. Currently we have verbose code which does nothing useful.

I'd also like to add a 3rd point to my comment above:

1. We don't have the self/_this workaround in TS, which could have mitigated point 1.
   It's a really weak point for the language. It should be addresses by offering a real solution.
   

You shouldn't be afraid to diverge from ES where it's truly problematic. Otherwise you limit the potential impact of TS.

I would be happy with Class.this, which would give a closure to class instance as programmer sees it. Just like self pattern. Binding should be left to developer as there already are constructs to handle this in JS.

@yaakovd - Not sure I understand the comment about requiring 'this' keyword on every class-member usage. JavaScript has the same behavior - both in ES5 and in ES6 classes. Also not sure I follow the point about not have a self/_this workaround - you can do that if you want in TS as well, or use arrow functions.

I think perhaps you are comparing TS classes to JS code written using the "closure" class style used in some JS code. That style has some benefits, including binding all members by default, but also generally has worse performance and interoperability with other code. Both in ES6 and in TypeScript, we have adopted the more commonly used "prototypal" class pattern as the "class" syntax. This does not itself solve the member binding problem, leaving it the same as it is in existing prototype based JS code.

@v3nom - Could you give an example of what the 'Class.this' approach you describe would look like?

The point is that some libraries change 'this' to some specific object and developers do not want to rebind the event handler, they just want to have alternative way of reaching initial this.

Self in JS:
or
Possible way of using self in TS:
I am not sure what would be the most idiomatic output for this in JS.