Polymorphic 'this' type

[Anders Hejlsberg (ahejlsberg)]

This PR implements polymorphic typing of this for classes and interfaces as inspired by #3694. The new features are:

• The type of this in an expression within a non-static class or interface member is considered to be an instance of some class that derives from the containing class as opposed to simply an instance of the containing class.
• The this keyword can be used in a type position within a non-static class or interface member to reference the type of this.
• When a class or interface is referenced as a type, all occurrences of the this type within the class (including those inherited from base classes) are replaced with the type itself.

This feature makes patterns such as fluent interfaces and covariant return types much easier to express and implement. Languages such as C++, Java, and C# use a somewhat involved generic pattern to emulate this feature, as described here.

An example:

classA{foo(){returnthis;}}classBextendsA{bar(){returnthis;}}varb: B;varx=b.foo().bar();// Fluent pattern works, type of x is B

In a non-static member of a class or interface, this in a type position refers to the type of this. For example:

classEntity{clone(): this {// Code to clone Entity}equals(other: this): boolean{// Code to compare Entity with another Entity}}

Each subclass of the above Entity will have a clone method that returns an instance of the subclass, and an equals method that takes another instance of the subclass.

The this type is a subtype of and assignable to the instance type of the containing class or interface, but not vice-versa (because this might actually be a subclass). That is a breaking change, and certain code patterns that previously compiled may now need an extra type annotation:

classA{getInstance(){// Should be getInstance(): Areturnthis;}}classBextendsA{getInstance(){returnnewB();}}

The example above now errors because the inferred return type of getInstance in A is this and the inferred type of getInstance in B is B, which is not assignable to this. The fix is to add a return type annotation for getInstance in A.

The polymorphic this type is implemented by providing every class and interface with an implied type parameter that is constrained to the containing type itself (except when the compiler can can tell that this is never referenced within the class or interface). That in particular turns a lot of previously non-generic classes into generic equivalents, causing more symbols and types to be created due to generic instantiation. The observed cost in batch compile time ranges from 0% in code that uses no classes to 6-7% in very class-heavy code.

Note that this PR specifically doesn't aim to implement other parts of #3694 such as this type annotations for functions. Those will be covered by other PRs if we choose to implement them.

[Anders Hejlsberg (ahejlsberg)]

Jon (@jbondc) Agreed, it might be good to show which class a particular this type belongs to in error messages and information produced by the language service.

[Deleted user (ghost)]

👏

[Ryan Cavanaugh (RyanCavanaugh)]

How does this handle the case where an interface extends a class that uses this ?

[Anders Hejlsberg (ahejlsberg)]

If one of the base types is a class (i.e. not an interface) we simply return true (because every class has a this type). We only return false from this function if the interface itself doesn't reference this, if every base type is an interface, and if no base interface has a this type.

[Ryan Cavanaugh (RyanCavanaugh)]

Need to un-comment the fourslash tests that were edited

[Anders Hejlsberg (ahejlsberg)]

Ryan Cavanaugh (@RyanCavanaugh) Yes, Mohamed Hegazy (@mhegazy) is looking at fixes for the failing fourslash tests.

[Jon (jbondc)]

Ideally these should not fail right? But only on instantiation.

[Anders Hejlsberg (ahejlsberg)]

No, they should fail. The first declaration infers type this for v, the second declaration specifies type MyGenericTestClass<T, U> for v. Those are not identical types, so error.

[Daniel Rosenwasser (DanielRosenwasser)]

Anders Hejlsberg (@ahejlsberg) I spoke with Ryan Cavanaugh (@RyanCavanaugh), Wesley Wigham (@weswigham), and Dan Quirk (@danquirk) about this, and I think there are some issues with the meaning of this in a type literal. Take the following:

interfaceThing{getResource(): {methodA(): this;methodB(): this;}}

In the current implementation, this refers to the type assignable to Thing; however, this doesn't accurately reflect the type of this when methodA is invoked off of its returned object. This could be very confusing for users because the intuition is that the method literally returns the expression this.

For either one semantics of the this type, a workaround exists to get the alternative semantics by extracting the resource type into its own interface.

However, if this refers to the enclosing type literal, then an easier fix exists by adding a type parameter to the method:

interfaceThing{getResource<OwnerTextendsThing>(): {a(): OwnerT;b(): this;}}

I think that we should go with the semantics that most-closely matches the runtime: in this case, the this type should refer to the type returned by getResource().

[Anders Hejlsberg (ahejlsberg)]

Daniel Rosenwasser (@DanielRosenwasser) You're incorrect about the current behavior, your example is actually an error:

interfaceThing{getResource(): {methodA(): this;// ErrormethodB(): this;// Error}}

The error reported is 'this' type is available only in a non-static member of a class or interface and I think that is the behavior we want. If at some point we decide to make it possible to reference this of a function or method (perhaps because the function declared a this type parameter as speculated about in #3694) the above would become valid, but for now it should be an error.

In order to reference an outer this in an object type literal you have to introduce a generic type and capture this as an argument:

interfaceResource<T>{methodA(): T;methodB(): T;}interfaceThing{getResource(): Resource<this>;}

Note, however, that you can capture the outer this in an object literal:

classA{foo(){return{x: this,f: ()=>this};}}

In order to write down the type inferred for the above, you'd have to resort to a temporary type:

interfaceFoo<T>{x: T;f(): T;}classA{foo(): Foo<this>{return{x: this,f: ()=>this};}}

[Anders Hejlsberg (ahejlsberg)]

Jon (@jbondc) I think the this type and mixins are largely orthogonal issues. I'd take the discussion up on one of the many mixin suggestion threads we already have going on and keep this one focused to the semantics and implementation of the this type.

[Daniel Rosenwasser (DanielRosenwasser)]

your example is actually an error

I actually was asking others about the implementation and it was our understanding that it was allowed; sorry about that. I didn't get the chance to try the branch out yesterday.

Note, however, that you can capture the outer this in an object literal:

classA{foo(){return{x: this,f: ()=>this};}}

But the .d.ts emit for that is currently not valid:

declareclassA{foo(): {x: this;f: ()=> this;};}

If I try to reuse that .d.ts file, I get:

foo.d.ts(3,12): error TS2526: 'this' type is available only in a non-static member of a class or interface.
foo.d.ts(4,18): error TS2526: 'this' type is available only in a non-static member of a class or interface.

[Anders Hejlsberg (ahejlsberg)]

Daniel Rosenwasser (@DanielRosenwasser)Mohamed Hegazy (@mhegazy) The .d.ts issue is tricky. Personally I think this is one of those situations where we should issue an error if a .d.ts is requested with guidance that a type annotation is required.

[Daniel Rosenwasser (DanielRosenwasser)]

Maybe clarify that this is not a built-in type keyword.

[Anatoly Ressin (Artazor)]

As I understand, polymorphic this type will greatly simplify the following code:

// interface Cloneable<T extends Cloneable<T>> {interfaceCloneable<TextendsCloneable<any>>{clone(): T;}

turns it into

interfaceCloneable{clone(): this;}

It's cool!

However It looks like that it solves only a half of a problem (ok, let it be 90% in common practices)

Am I right, that the system

// interface Vertex<V extends Vertex<V,E>, E extends Edge<V,E>> {interfaceVertex<VextendsVertex<any,any>,EextendsEdge<any,any>>{incoming: E[];outgoing: E[];}//interface Edge<V extends Vertex<V,E>, E extends Edge<V,E>> {interfaceEdge<VextendsVertex<any,any>,EextendsEdge<any,any>>{from: V;to: V;}classCityextendsVertex<City,Road>{constructor(publicname: string){this.incoming=[];this.outgoing=[];}}classRoadextendsEdge<City,Road>{constructor(publicdistance: number,publicfrom: City,publicto: City){this.from.outgoing.push(this);this.to.incoming.push(this);}}varLA=newCity('Los Angeles');varSF=newCity('San Francisco');varhyperloop=[newRoad(558.68,LA,SF),newRoad(558.68,SF,LA)]console.log(hyperloop[0].from.outgoing[0].to.name)// stronly typed

still could not benefit from this type without introducing high order types into TypeScript ?

I could imagine the following implementation

// interface Vertex<E<T> extends Edge<T>> -or-interfaceVertex<EextendsEdge>{incomming: E<this>[];outgoing: E<this>;}// interface Edge<V<T> extends Vertex<T>> -or-interfaceEdge<VextendsVertex>{from: V<this>;to: V<this>;}classCityextendsVertex<Road>{ ... }classRoadextendsEdge<City>{ ... }

where for high order types the constraint
<G1 extends G2>
could be formulated as

G1<T> extends G2<T> recursively for every T

Am I right? Or there is a simpler solution that I've missed?

[Anatoly Ressin (Artazor)]

I mean that this type alone solves only direct type recursion problem. Mutually recursive constraints are still not expressible.
Anders Hejlsberg (@ahejlsberg) ?

[Anders Hejlsberg (ahejlsberg)]

Anatoly Ressin (@Artazor) Correct, the polymorphic this helps in the simple (and common) case, but the general solution likely requires higher-order types of some form since the dependent types can't otherwise refer to each other's this.

[vilicvane (vilicvane)]

🎉 👍

[Mitja P (mitjap)]

should this also support this syntax?

interface A<T> { }
interface B<T extends A<T>> { }

[Mohamed Hegazy (mhegazy)]

Mitja P (@mitjap): see #2225

[Marcus (mjohnsonengr)]

This seems to cause the following issue. In the example below in the getProperty() method, style is assigned to this. This used to be able to infer the type Style, but the latest code including this pull request does not, and the assignment to style at the end of the while loop throws an error, "Type 'Style' is not assignable to type 'this'.

Is this expected?

class Style {
public property: number;
public basedOn: string;
/** if property is null, get from basedOn */
public getProperty(): number {
var style = this; // used to infer type of Style
while (style !== null) {
if (style.property)
return style.property;
// get style referenced by basedOn
style = style.basedOn === null ? null : getStyle(style.basedOn);
}
return null;
}
}

[Ryan Cavanaugh (RyanCavanaugh)]

Marcus (@mjohnsonengr) this is the intended behavior. If there were a subclass of Style, the result of getStyle would be unassignable to a variable of type this (i.e. attempting to assign a Style to a SuperCoolStyle during a polymorphic invocation of getProperty).

I'd recommend writing var style: Style = this; - that will solve the issue

[Marcus (mjohnsonengr)]

Nevermind, saw the referenced issue, #5056

[Marcus (mjohnsonengr)]

Ahh, but thank your for your reply Ryan Cavanaugh (@RyanCavanaugh)! :)

[Aykut Alpgiray Ates (aalpgiray)]

so what should I do to use this instead of state below

functionNavigatableRecordCreator(defaultValues: {[key: string]: any;},name?: string){abstractclassNavigatableRecord<PextendsNavigatableRecord<P>>extendsRecord(defaultValues,name){SetValue<T>(fn: (x: NavigableObject<P>)=>NavigableObject<T>,value: T,state: P){returnthis.setIn(fn(newNavigableObject<P>(state)).getPath(),value)// can I use this instead of state here}}returnNavigatableRecord;}

[shelby3]

Anders Hejlsberg (@ahejlsberg)wrote:

Each subclass of the above Entity will have a clone method that returns an instance of the subclass, and an equals method that takes another instance of the subclass.

The this type is a subtype of and assignable to the instance type of the containing class or interface, but not vice-versa (because this might actually be a subclass).

As I wrote in #3694, how can polymorphic clone(): this be implemented if it is not legal to assign an instance of the subclass to this??? It seems instead the compiler will need to deduce that inheritance from Entity types clone() as an abstract method even though the base has an implementation, so as to insure that each subclass provides a unique implementation.