Supporting 'this' type

Background

We've had a few requests to support this typing (like #229). This proposal addresses the use cases for a function 'this' type, a class 'this' type, and a corresponding feature for interfaces.

Motivating Examples

Extension (lightweight mixin)

interface Model {
  extend<T>(t: T): <type of containing interface> & T;
}

interface NamedModel extends Model {
  name: string;
}

declare function createNameModel(): NamedModel;

var modelWithNameAndAge = createNamedModel().extend({
  age: 30
});
modelWithNameAndAge.name; //valid
modelWithNameAndAge.age; // valid

Safe instantiation

function f() {
  this.x = 3;
}
var g = new f(); // gives type an easy way to check f's body or specify instantiated type

Safe method invocation

function f() {
  this.x = 3;
}
var obj = {y: "bar", f: f};
obj.f(); // can’t easily error

Well-typed fluent APIs (also useful for cloning)

class Parent {
  setBase(property, value): <whatever the child class is> {
    this._secretSet(property, value);
    return this;
  }
}

class Child extends Parent { 
  name:string;
}

var c = new Child();
console.log(c.setBase("foo", 1).setBase("bar", 2").name);  //valid

Design

To support the motivating examples, we introduce a 'this' type. The 'this' type should follow the intuition of the developer. When used with classes, 'this' type refers to the type of the class it finds itself in. With functions, 'this' allows you to further document how the function will be used as a constructor and in what context it can be invoked while in an object.

Classes and 'this'

A class that uses a 'this' is referring to the containing named class. In the simplest example:

class C {
  myThis(): this { return this; }
}
var c = new C();
var d = c.myThis();

We trivially map the 'this' type in the invocation of myThis() to the C type, giving 'd' type C.

The type of 'this' will follow with subclasses. A subclass sees any 'this' in the type of its base class as its own type. This allows more a fluent API, as in this example:

class C {
  myThis(): this { return this; }
}
class D extends C {
  name: string;
}
var D = new D();
d.myThis().name = "Joe"; //valid

For this to work correctly, only 'this' or something that resolves to 'this' can be used. Something which looks like it should work correctly, but can't work safely is this example:

class C {
  newInstance(): this {
    return new C(); // error, 'this' only works with this expressions
  }
}

Functions and 'this'

Functions gain the ability to talk about the shape of the 'this' pointer that is visible in the function body. The design here leverages the type variables of the function to describe what the shape of 'this' has:

function f<this extends {x:number}>() {
  this.x = 3;
}

This is fairly readable, and we could use syntax coloring/tooling to help signify that the 'this' here is a special type variable that is implied by all functions.

Once the type of 'this' is described for functions, we can check the inside of the function body, where this is used:

function f<this extends {x:number}>() {
  this.x = 3;
  this.y = 6; //error: y is not available on this
}

We can also check invocation sites:

var o = {myMethod: f, y: "bob"};
o.myMethod(); //error: o does not match the shape of 'this' for 'myMethod'

We may even want to error on the assignment when object is first created instead of the invocation site.

Interfaces and 'this'

Similarly to classes, interfaces currently lack the the ability for a type to refer to itself. While an interfaces can refer to itself by name, this limits the ability of interfaces that extend the original interface. Here, we introduce 'this' as a way for interfaces to do this:

interface Model {
  clone(): this;
}

interface NamedModel extends Model {
  name: string;
}

var t:NamedModel;
t.clone().name; // valid

For this to work, 'this' refers to the containing named type. This helps eliminate ambiguities like this:

interface I {
  obj: { myself: this; name: string };
}

In this example, 'this' refers to I rather than the object literal type. It's trivial to refactor the object literal type out of the class so that you can describe a 'this' that instead binds to the object literal itself.

Motivating examples (Redux)

In this section, we re-write the motivating examples using the proposed functionality.

Extension (lightweight mixin)

interface Model {
  extend<T>(t: T): this & T;
}

interface NamedModel extends Model {
  name: string;
}

declare function createNameModel(): NamedModel;

var modelWithNameAndAge = createNamedModel().extend({
  age: 30
});
modelWithNameAndAge.name; //valid
modelWithNameAndAge.age; // valid

Safe instantiation

function f<this extends {x:number}>() {
  this.x = 3;
}
var g = new f(); // gives type an easy way to check f's body or specify instantiated type

Safe method invocation

function f<this extends {x: number}>() {
  this.x = 3;
}
var obj = {y: "bar", f: f};
obj.f(); // error: f can not be invoked on obj, missing {x: number}

Well-typed fluent APIs (also useful for cloning)

class Parent {
  setBase(property, value): this {
    this._secretSet(property, value);
    return this;
  }
}

class Child { 
  name:string;
}

var c = new Child();
console.log(c.setBase("foo", 1).setBase("bar", 2").name);  //valid

Should methods now all implicitly gain a this type variable? This would prevent users from shooting themselves in the foot. For example:

class C {
    prop: number;
    method() {
        return this.x;
    }
}

let c = new C();
let removedMethodHandle = c.method;

// the following would error
console.log(removedMethodHandle());

Daniel Rosenwasser (@DanielRosenwasser)

Daniel Rosenwasser (@DanielRosenwasser) possibly? Though I suspect that won't give you what you need. If the 'this' type shows up in the type of c.method, if you pass it to a callback that forgets the 'this' piece of the type, you won't catch the error.

'this' is a good idea. Also it could be applied to the 'call', 'bind' and 'apply' scenarios.

For Example:

class A {
    name: string;

    setName<this extends { name: string;}>(val:string) {
        this.name = val;
    }
}


class B {
    somethingElse: string;
 }

class C { name: string; }

var setName = new A().setName;
var b = new b();
var c = new C();
setName.apply(b, ["hello"]); //error
setName.call(b, "hello"); //error
setName.bind(b)("hello"); //error


setName.apply(c, ["hello"]); //ok
setName.call(c, "hello"); //ok
setName.bind(c)("hello"); //ok

👍 for the proposal

For the interface and class part, it seems this type overlaps a lot with F-bounded polymorphism. Can this type cover the latter?

Some questions that come to mind...

(1) Your proposal doesn't specifically say, but I assume within a class this would denote a type that behaves like a subtype of the containing class (effectively like a type parameter with the current class as a constraint). That means we'd break the following code:

class C {
    foo() {
        var x = this;
        x = new C();
    }
}

(2) The proposal doesn't specify what the type of a method in a class is. For example:

class C {
    f() { }
}
var c = new C();
var f = c.f;  // Ideally of type <this extends C>() => void
f();          // Should be an error

the type of f currently is () => void, but I assume it would now be <this extends C>() => void. That would ensure f can't accidentally be called without a proper this.

(3) What are the type compatibility rules for function types with this type arguments? For example:

var c = new C();
var f: () => void = c.f;  // Is this allowed?

If we treat this as a type parameter, the above assignment would be allowed because we erase type parameters when checking assignment compatibility of signatures. That might in fact be the right thing to do because anything stricter would break a lot of existing code. But it is something we need to consider.

Anders Hejlsberg (@ahejlsberg)

Anders Hejlsberg (@ahejlsberg), my comment brings up (2). From what I understand, jonathandturner responded that because of your point in (3), we lose the benefit resulting from (2) because of cases where c.f is fed into a callback.

We could instead always take this constraints into account, and say that if an instance method never accesses this, it does not receive a this constraint. This way, we'd only break code in cases where a this handle was actually used, though, I could see it as slightly awkward to enforce this consistency.

Couldn't the above use case be covered by this?

interface Foo {
  bar(this: Foo & Bar): void;
}

interface Bar {
  bar(this: Foo | Bar): void
}

That, I believe, fits closer to the emerging syntax consensus in #229.

IMPinball

IMPinball could you clarify which use case you're referring to?

Sorry...I meant the this in function types in the main proposal. It wasn't specifically about your comment...probably should have mentioned jonathandturner.

Also, as for that mixin model, there's already half a dozen mixin proposals out there, but this specific version proposed in the main bug is probably not the best way to go (feels incomplete).

Anders Hejlsberg (@ahejlsberg)

Anders Hejlsberg (@ahejlsberg) - yeah, good to call out (1). Though I allude to it in the proposal by talking about assignment compat with 'this', I think the way you spell it out works better and gives a better intuition.

Daniel Rosenwasser (@DanielRosenwasser) - We should explore implied 'this' constraint more, and try it out on some real world code to see what impact it might have.

IMPinball - agreed. This isn't intended to be used as a complete mixin solution, rather a way of modeling extension like how some libraries (like Ember) do extensibility. For a full mixin story, you'd want the type-checking part (including something like intersection types) combined with a code generation piece.

Jon (@jbondc)

Jon (@jbondc) - do you have an example you think would cause problems?

I'm not sure exactly what your semantics are here, since this isn't valid JS/TS.

A related example in valid JS should show it a bit better:

class A extends mixin(B, C, D) {
   me(): this { return this } // includes me(), b(), c(), d, e?
}

So yeah, from the original example in the writeup a subclass would have a 'this' type that reflects the shape of the class. Unfortunately, I don't think there's enough descriptive power in the type system to cover the mixin forms.

(not to say there couldn't be in the future)

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@mhegazy) I have a couple clarification questions:

I'm guessing you're just referring to literal ES5 functions?
Does func(function (x: string) { ... }) trigger noImplicitThis if the callee doesn't define a this type for the argument, such as in func(f: (x: string) => any): any)?

Methods can also declare a this parameter:

class C {
  totalCallback(this: void, e: Event); // assign to me!
}

noImplicitThis is triggered by this expressions in the body of a function. It is independent of assignability checks, which default to any if no this type is declared.

In other words, this is an implicit this error:

function f(n: number) {
  return this.m + n; // error -- this: any
}

But this is a normal old assignability error:

function f(this: void) { ... }
class C {
    m(this: this) { ... }
}
let c: C;
c.m = f; // error!

Nathan Shively-Sanders (@sandersn)

Nathan Shively-Sanders (@sandersn) Thanks! 😄

Nathan Shively-Sanders (@sandersn)

Nathan Shively-Sanders (@sandersn) Thanks! I think the approach to declare the first function parameter as this: myType is the best one.

IMO the syntax is a bit verbose, instead of

function f<this extends {x:number}>() {
  this.x = 3;
}

why not simply:

function f() {
  let this: {x:number};
  this.x = 3;
}

nino-porcino (@nippur72)

nino-porcino (@nippur72) no, that's not good. You're actually declaring a variable named this and not initializing it (undefined). The compiled code would have: var this; in it and shoud cause a runtime error

~~has this landed in 2.0 ? I just copied this in a 2.0 project:~~

function f<this extends {x:number}>() {
  this.x = 3; 
}

~~but it tells me:~~

index.ts(1,12): error TS1139: Type parameter declaration expected.
index.ts(1,17): error TS1005: ';' expected.
index.ts(1,35): error TS1109: Expression expected.
index.ts(1,37): error TS1109: Expression expected.
index.ts(1,39): error TS1005: ';' expected.

Sorry, I see that the syntax is now

function f(this:{x:number}>() {
  this.x = 3; 
}

Daniel Rosenwasser (@DanielRosenwasser)

jonathandturner wrote:

class C {
  newInstance(): this {
    return new C(); // error, 'this' only works with this expressions
  }
}

How can polymorphic clone(): this be implemented if the above is not allowed? A class which implements the interface or abstract clone() method, could be extended by another class. It seems the compiler will need to deduce that inheritance from C types newInstance() as an abstract method even though the base has an implementation, so as to insure that each subclass provides a unique implementation.

function f<this extends {x:number}>() {
  this.x = 3;
  this.y = 6; //error: y is not available on this
}

Don't you mean implements instead of extends, since f is not allowed to add new member properties?

var o = {myMethod: f, y: "bob"};
o.myMethod(); //error: o does not match the shape of 'this' for 'myMethod'

I presume new o.myMethod() is legal.

jonathandturner wrote:

Daniel Rosenwasser (@DanielRosenwasser) wrote:

Should methods now all implicitly gain a this type variable? This would prevent users from shooting themselves in the foot. For example:

possibly? Though I suspect that won't give you what you need. If the 'this' type shows up in the type of c.method, if you pass it to a callback that forgets the 'this' piece of the type, you won't catch the error.

Google SoundScript's presentation says on page 24, "method extraction only allowed when this : any".

Anders Hejlsberg (@ahejlsberg) wrote:

class C {
    f() { }
}
var c = new C();
var f = c.f;  // Ideally of type <this extends C>() => void
f();          // Should be an error
the type of f currently is () => void, but I assume it would now be <this extends C>() => void. That would ensure f can't accidentally be called without a proper this.

That seems to be a nice generalization of the aforementioned plan for Google's SoundScript.

(3) What are the type compatibility rules for function types with this type arguments? For example:
var c = new C();
var f: () => void = c.f;  // Is this allowed?
If we treat this as a type parameter, the above assignment would be allowed because we erase type parameters when checking assignment compatibility of signatures. That might in fact be the right thing to do because anything stricter would break a lot of existing code. But it is something we need to consider.

That would break the aforementioned soundness expected by Daniel Rosenwasser (@DanielRosenwasser), which I see he pointed out.

class C {
    foo() {
        var x = this;
        x = new C();
    }
}

Why are you inferring the type of x: this instead of x: C?

Can we also propagate this to work with static functions?

Suppose, we have following code:

class C {
    constructor() { console.log("C"); }
    static foo() { return new this(); }
}

class D extends C { 
    constructor() {
        super();
        console.log("D");
    }
    bar() { return 42; }
}

var d = D.foo(); // valid and works. Will output C and then D

console.log(d instanceof D); // true

console.log((<D>d).bar()); // 42

Can we add a possibility to type it correctly?

Of course you can. TypeScript has very advanced type system now.

class C {
  static foo = function <D extends C>(this: {new(): D}) {return new this()}
}

class D extends C {
  bar() { return 42}
}

var d = D.foo()
d.bar()

That looks like very dirty hack, although it works.

Is it possible to get the Type of my class I am currently working in? for example

export class A{
    // constructor + methods
    // can use `A` as a return Type
}
export class B extends A{
    public b:any = this;
    // here in my methods if I use a return type of `B` it implies class `A`type
    // how do I use `B` as a type?
    fun():B {
        const self = this.b;
        let hmm:B;  // Variable in question

        // Logic to fill variable hmm with self like item

        return hmm;  // Error: Type 'A' is not assignable to type 'B' , property 'some class var' is not in type 'A.
    }
}

Marcus (@marcusjwhelan)

Marcus (@marcusjwhelan) I think you want:

export class A {
}
export class B extends A {
    fun(): this {
        return this;
    }
}

https://egghead.io/lessons/typescript-create-a-fluent-api-using-typescript-classes 🌹

Basarat Ali Syed (@basarat)

Basarat Ali Syed (@basarat) ah thank you for the quick reply. Although I actually figured out that it was fault code on my part. The reason I could not use the class as a type was an issue with me assigning the variable that was to be returned as the parent type, copy paste error.

Navigation Menu

Repository navigation

Supporting 'this' type #3694

Background

Motivating Examples

Extension (lightweight mixin)

Safe instantiation

Safe method invocation

Well-typed fluent APIs (also useful for cloning)

Design

Classes and 'this'

Functions and 'this'

Interfaces and 'this'

Motivating examples (Redux)

Extension (lightweight mixin)

Safe instantiation

Safe method invocation

Well-typed fluent APIs (also useful for cloning)

51 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Supporting 'this' type #3694

Description

Background

Motivating Examples

Extension (lightweight mixin)

Safe instantiation

Safe method invocation

Well-typed fluent APIs (also useful for cloning)

Design

Classes and 'this'

Functions and 'this'

Interfaces and 'this'

Motivating examples (Redux)

Extension (lightweight mixin)

Safe instantiation

Safe method invocation

Well-typed fluent APIs (also useful for cloning)

Activity

DanielRosenwasser commented on Jul 1, 2015

sophiajt commented on Jul 1, 2015

prabhjots commented on Jul 1, 2015

HerringtonDarkholme commented on Jul 3, 2015

ahejlsberg commented on Jul 4, 2015

DanielRosenwasser commented on Jul 4, 2015

dead-claudia commented on Jul 7, 2015

DanielRosenwasser commented on Jul 7, 2015

dead-claudia commented on Jul 7, 2015

sophiajt commented on Jul 7, 2015

sophiajt commented on Jul 17, 2015

sophiajt commented on Jul 17, 2015

sophiajt commented on Jul 17, 2015

51 remaining items

dead-claudia commented on Apr 8, 2016

sandersn commented on Apr 8, 2016

dead-claudia commented on Apr 8, 2016

vitaly-t commented on May 9, 2016

nippur72 commented on Jun 21, 2016

Zorgatone commented on Jun 21, 2016

nippur72 commented on Jul 15, 2016

shelby3 commented on Sep 10, 2016

yhaskell commented on Oct 5, 2016

HerringtonDarkholme commented on Oct 5, 2016

yhaskell commented on Oct 5, 2016

marcusjwhelan commented on Apr 18, 2017

basarat commented on Apr 18, 2017

marcusjwhelan commented on Apr 18, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions