This project is read-only.


Specifying the type of implicit `this`


Related to this exchange ( I propose that it be added to the language a way to specify the expected type of the implicit this parameter in the function signature.

A function which is expected to be .call()ed or .apply()ed with a non-locally-available argument as its eventual this context could have an optional first parameter named this for which a type can be asserted.

// current:

var delegate = function() { this.doSomething(); }; // lack of type safety;; // no complaint

// should be:

var delegate = function(this : CanDoSomething) { this.doSomething(); };;; // type error
Closed Jul 28, 2014 at 11:18 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:


rwaldron wrote Oct 18, 2012 at 5:16 PM


var delegate = function(this : CanDoSomething) { this.doSomething(); };

...Looks like Python and breaks TypeScript as a "Superset of JavaScript"

admiristrator wrote Oct 19, 2012 at 3:08 AM

I don't think it breaks the "superset of javascript". Please elaborate on that claim.

In javascript, it's not allowed (I strongly believe) to have a parameter to a function named this. So there is no javascript which could be misinterpreted by the TypeScript compiler by making an option first this parameter allowed for the purposes of type specification.

Further, at call-sites, whether called normally, with .call(), or .apply() the this parameter would not be shown as part of the signature. (Though, it'd probably be good to indicate the expected type somehow)

rwaldron wrote Oct 19, 2012 at 4:23 AM

No, you can't have a named parameter called "this", but making the function's formal parameters "appear" to have a leading scope parameter but then it's "not [] shown" as you've described, or simply removed—which is what I was assuming you meant—that's what breaks the "superset of JavaScript".

If a context type is to be definable, it should simply be done by other means, not by overloading the formal parameter list.

admiristrator wrote Oct 31, 2012 at 2:58 PM

How is that particular syntax change different from the kind of change that TypeScript's type specifiers require? Having : string after a parameter will break javascript too. Having a parameter named this would not be valid and could never be found in valid javascript, so it's presence (just like the presence of the type specifiers) means that this MUST mean the special TypeScript usage.

C# extension methods do a similar syntax but of course the meaning is different. And I doubt TypeScript needs to reserve that syntax for extension methods - I don't see a need for extension methods in TypeScript/javascript since it's very easy to do the same thing by augmenting prototypes.

Regarding " should simply be done by other means...", Do you have a better suggestion for a syntax?

Perhaps there's a bigger reason that a type specifier for this isn't allowed or isn't necessary and I'm looking forward to that explanation.

basarat wrote Aug 22, 2013 at 11:06 AM

The strongest vote count seems to be on this issue : +1 there

basarat wrote Aug 22, 2013 at 11:07 AM

vote for the same feature here :