Proposal: 'typeon' operator

[rotemdan]

Proposal: 'typeon' operator

The typeon operator references the type associated with an interface or class property, but in contrast to typeof, refers to it through the containing Type itself. I.e. directly queries the type set on the property rather than the type of an instance of it:

interface MyInterface {
 prop: number;
}

let val: typeon MyInterface.prop; // type of val is 'number'

This would work with any property, including ones contained in anonymous and nested interfaces:

interface MyInterface {
 obj: {
 x: number;
 y: number;
 }
}

let myX: typeon MyInterface.obj.x; // type of myX is now 'number'

Generic interfaces:

interface MyInterface<T> {
 obj: {
 x: T;
 y: T;
 func: (arg: T) => T;
 }
}

let f: typeon MyInterface<number>.obj.func; // type of f is now (arg: number) => number

It would be possible to reference the property types at any scope, including within the referenced declaration itself:

interface MyInterface {
 val: string;
 anotherVal: typeon MyInterface.val;

 obj: {
 x: number,
 y: number;
 func(arg:number): typeon MyInterface.obj.x;
 }
}

The this type reference

A special this type reference could be supported for this very purpose. this would be scoped to the closest containing interface, and that would also apply to anonymous ones:

interface MyInterface {
 val: string;
 anotherVal: typeon this.val;

 obj: {
 x: number,
 y: number;

 // Note: 'this' is scoped to the anonymous interface here. 
 // 'typeon this.val' would give an error.
 func(arg: string): typeon this.x; 
 }
}

It would also be available in interfaces declared through type declarations and for purely anonymous ones:

type MyType = { 
 name: string;
 age: number;
 query: (username: typeon this.name) => typeon this.age;
}

let test: { x: number, y: typeon this.x }

and to classes, which would also include references to the types of properties declared in base classes when using this (a possible extension could also include support for super):

class UserBase {
 id: string;
}

class User extends UserBase {
 age: number;

 chatWithUser(id: typeon this.id): { id: typeon User.id, age: typeon User.age } {

 // The first argument for 'chatWith' is expected to be a string here, so this works.
 chatWith(id); 
 ..
 }
}

In a class declaration, typon this can only be used from instance positions. To reference static members, the name of the class would be used with typeof (note: no equivalent typeof this or a standalone this type is included in this proposal).

class Example {
 val: number;
 static val: string;

 instanceFunc1(): typeon this.val; // OK, resolves to 'number'
 instanceFunc2(): typeof Example.val; // OK, resolves to 'string'

 static staticFunc1(): typeon Example.val; // OK, consistent with external references.
 static staticFunc2(): typeof Example.val; // OK, resolves to 'string'
}

This was chosen to improve clarity and for consistency with generic classes, where the instantiated values of generic parameters are not available at static positions:

class Example<T> { // The example is given where T = number
 val: T;
 static val: string;

 instanceFunc1(): typeon this.val; // OK, resolves to 'number'.
 instanceFunc2(): typeof Example.val; // OK, resolves to 'string'

 static staticFunc1(): typeon Example<number>.val; // OK, consistent with external references.
 static staticFunc2(): typeof Example.val; // OK, resolves to 'string'
}

let c = new Example<number>();

Example use cases

Using these ad-hoc references would make it easier to express of the semantic intention for the usage of the type, and automatically "synchronize" with future changes to the type of the referenced property. This both reduces effort and prevents human errors:

class UserBase {
 // The type for 'id' has now changed, this usually means that all similar 
 // semantic usages of it would need to be manually checked and updated, 
 // this includes ones in derived classes.
 id: string | number; 
}

class User extends UserBase {
 age: number;

 // The type of the 'id' argument and anonymous interface property has 
 // automatically synchronized with the one set in the base class!
 // This ensures that they will always be consistent and will propagate type errors 
 // into the body of the function.
 chatWithUser(id: typeon this.id): { id: typeon User.id, age: typeon User.age } { 

 // The first argument for 'chatWith' is expected to be a string here, 
 // but now the type of 'id' has changed to string | number so will error.
 // This compile-time error is possible because the type was referenced with 'typeon'
 chatWith(id); // Error! type 'string' is not assignable from 'string | number'
 ..
 }
}

Another effective use is to encapsulate and reference anonymous types within a class or interface declaration without needing to declare additional type aliases or interfaces. This yield a different style of coding:

class Process {
 id: number;

 state: {
 memoryUsage: {
 real: number;
 virtual: number;
 private: number;
 };

 processorUsage: Array<{ index: number, percentage: number }>;
 }

 constructor() {
 ...
 }
 ..
}

class OSQuery {
 static queryMemoryUsage(id: typeon Process.id): typeon Process.state.memoryUsage {
 return { 
 real: OS.getRealUsage(id), 
 virtual: OS.getVirtualUsage(id), 
 private: OS.getPrivateUsage(id)
 };
 }

 static queryProcessorsUsage(id: typeon Process.id): typeon Process.state.processorUsage {
 result: typeon Process.state.processorUsage;

 for (let i=0; i< OS.processorCount; i++) {
 result.push( { index: i, percentage: OS.getProcessorUsage(id, i) })
 }

 return result;
 }

 static queryProcessState(id: typeon Process.id): typeon Process.state {
 return { 
 memoryUsage: this.queryMemoryUsage(id),
 processorUsage: this.queryProcessorsUsage(id)
 }
 }
 ..
}

In the conventional style of coding, 4 auxiliary interfaces or type aliases would need to be declared to achieve this:

interface ProcessorUsageEntry {
 index: number;
 percentage: number;
}

interface MemoryUsage {
 real: number;
 virtual: number;
 private: number; 
}

type ProcessorID = number; // aliased in case that associated type changes

interface ProcessState {
 id: ProcessorID;
 memoryUsage: MemoryUsage;
 processorUsage: Array<ProcessorUsageEntry>
}

Reusing the syntax to reference a class instance type

It is also possible to naturally extend the syntax to reference a type that only includes members of a class instance (typeof MyClass only gives the type of the constructor):

class MyClass {
 instanceProp: number;
 static staticProp: string;

 constructor(arg: boolean) {
 ..
 }
}

let a: typeof MyClass; // 'a' now has type { staticProp: string, new (arg: boolean) }

let b: typeon MyClass; // 'b' now has type { instanceProp: number }

Equivalent reduction to named type aliases

This can be internally implemented in the compiler like this:

Source:

interface MyInterface {
 val1: string;
 val2: typeon this.val1;
 val3: typeon this.val2;

 obj: {
 x: number,
 y: number;

 func(arg: string): typeon this.x; 
 }
}

Reduction:

type TypeOn_val1 = string;
type TypeOn_val2 = TypeOn_val1;
type TypeOn_val3 = TypeOn_val2;

type TypeOn_obj_x = number;
type TypeOn_obj_func_returnType = TypeOn_obj_x;

type TypeOn_obj = {
 x: TypeOn_obj_x;
 y: number;

 func(arg: string): TypeOn_obj_func_returnType;
}

interface MyInterface {
 val1: TypeOn_val1;
 val2: TypeOn_val2;
 val3: TypeOn_val3;

 obj: TypeOn_obj;
}

Example with generic interfaces:
Source:

interface MyGenericInterface<T> {
 val1: T;
 val2: typeon val1;

 obj: {
 a: Array<T>,

 func(arg: T): typeon this.a; 
 }
}

Reduction (this uses the new generic type alias declarations introduced in 1.6):

type TypeOn_val1<T> = T;
type TypeOn_val2<T> = TypeOn_val1<T>;

type TypeOn_obj_a<T> = Array<T>;
type TypeOn_obj_func_returnType<T> = TypeOn_obj_a<T>;

type TypeOn_obj<T> = {
 a: TypeOn_obj_a<T>;

 func(arg: T): TypeOn_obj_func_returnType<T>
};

interface MyGenericInterface<T> {
 val1: TypeOn_val1<T>;
 val2: TypeOn_val2<T>;

 obj: TypeOn_obj<T>;
}

Possible issues and their solutions

Detect and error on circular references:

interface SelfReferencingPropertyType {
 x: typeon this.x; // Error: self reference
}

interface EndlessLoop {
 x: typeon this.y; // Error: indirect self reference
 y: typeon this.x; // Error: indirect self reference
}

This would happen automatically through the reduction described above. The error currently reported through type is "Error: type 'TypeOn_EndlessLoop_y' circularly references itself".

Current workarounds

It is currently possible to partially emulate this using typeof with a "dummy" instance of the type:

interface MyInterface {
 obj: {
 x: number,
 y: number
 }
}

let dummy: MyInterface;

let val: typeof dummy.obj;

And even:

interface MyInterface {
 obj: {
 x: number,
 y: typeof dummy.obj.x;
 }
}

interface AnotherInterface {
 func(arg:number): typeof dummy.obj;
}

var dummy: MyInterface;

Though these workarounds requires a globally scoped variable, and not always possible or desirable for use in declaration files. They also cannot support keywords like this (or super) thus cannot be used within anonymous types.

References to generic parameters cannot be emulated:

interface MyInterface<T> {
 x: T;
 y: typeon this.x; // Not possible to emulate this
}

[Originally described at #4555]

[danquirk]

Can the typeof operator not be extended to support these cases?

[DanielRosenwasser]

Can the typeof operator not be extended to support these cases?

I believe it would be ambiguous for classes:

class C {
 static prop;
 prop;
}

var p: typeof C.prop;

[kitsonk]

Obviously introducing another keyword is icky, especially for a bit of an edge case. For the class use case, the following would seem logical to me:

class C {
 static prop: number;
 prop: string;
}

let p: typeof C.prop = 'foo'; // p typeof string
let q: typeof typeof C.prop = 1; // q typeof number

[rotemdan]

A more practical example to demonstrate its real-world usefulness:

Encapsulate and reference anonymous types (through the equivalent of "auto-aliasing") in a class or interface without needing to declare additional external type aliases or interfaces. This allow a different style of coding:

class Process {
 id: number;

 state: {
 memoryUsage: {
 real: number;
 virtual: number;
 private: number;
 };

 processorUsage: Array<{ index: number, percentage: number }>;
 }

 constructor() {
 ...
 }
 ..
}

class OSQuery {
 static queryMemoryUsage(id: typeon Process.id): typeon Process.state.memoryUsage {
 return { 
 real: OS.getRealUsage(id), 
 virtual: OS.getVirtualUsage(id), 
 private: OS.getPrivateUsage(id)
 };
 }

 static queryProcessorsUsage(id: typeon Process.id): typeon Process.state.processorUsage {
 result: typeon Process.state.processorUsage;

 for (let i=0; i< OS.processorCount; i++) {
 result.push( { index: i, percentage: OS.getProcessorUsage(id, i) })
 }

 return result;
 }

 static queryProcessState(id: typeon Process.id): typeon Process.state {
 return { 
 memoryUsage: this.queryMemoryUsage(id),
 processorUsage: this.queryProcessorsUsage(id)
 }
 }
 ..
}

In the conventional style of coding, 4 auxiliary interfaces or type aliases would need to be declared here: ProcessID, ProcessState, ProcessMemoryUsage, ProcessProcessorUsage.

[benliddicott]

Daniel Rosenwasser (@DanielRosenwasser) , Dan Quirk (@danquirk):

Actually you can do these type deductions already, using a type inference hack. That means the type system can already do it, so it is really syntactic support which is required:

class MyClass {
 instanceProp: number;
 static staticProp: string;

 constructor(arg: boolean) {
 // ..
 }
}


 function func<T>(a: T): { a: T } { return { a: a }; };

 // a has type string. This works today using typeof syntax.
 let a: typeof MyClass.staticProp = "";

 // Typeof doesn't work with instance properties, but type inference can still deduce the type.
 // b has the type number.
 let b = false ? (<MyClass>(void 0)).instanceProp : void 0;

 // c has type {a: number}. 
 // Again, type inference can deduce the type without evaluating the expression
 let c = false ? (func(<number>(void 0))) : void 0;

Proposal: Allow arbitrary expressions as argument to typeof. These "type expressions" would not be evaluated, only the type deduction would take place at compile time.

If typeof accepted arbitrary expressions instead of identifiers, this would meet the need, I think.

class MyClass {
 instanceProp: number;
 static staticProp: string;

 constructor(arg: boolean) {
 // ..
 }
}


 function func<T>(a: T): { a: T } { return { a: a }; };

// b has type of the instanceProp property of MyClass.
let b: typeof (<MyClass>(void 0)).instanceProp; 
// c has same type as the return value of func(1), (but func is not evaluated).
let c: typeof (func(<number>(void 0))); 

Further proposal: Allow (<typename>) as a shorthand for (<typename>(void 0)) within a type expression. This would simplify writing type expressions for such uses as Rotem Dan (@rotemdan) describes. so typeof func(<number> 10).a could be written typeof func(<number>).a

[yortus]

Proposal: Allow arbitrary expressions as argument to typeof. These "type expressions" would not be evaluated, only the type deduction would take place at compile time.

I agree with this approach. It solves all the cases mentioned here. It handles anonymous types. It's not ambiguous with classes:

class C {
 static prop;
 prop;
}

var pStatic: typeof C.prop;
var pInstance: typeof new C().prop;

And the compiler can already do this, it just doesn't expose the ability. This would just remove its limitations.

C++ has exactly this operator, it is called decltype and it maps an expression to a type without evaluating the expression. Given the limitations currently placed on typeof, it could be extended to work just like decltype without a breaking change. It would become far more useful.

[rotemdan]

Troy Gerwien (@yortus), benliddicott

A main goal and benefit of the approach I presented is to allow a clean and natural way to reference into nested anonymous types like is demonstrated in this previous comment. Without a concise and readable syntax that would not generally be a practical thing to do. It was designed with the full intention of becoming a mainstream and usable pattern, not just an "advanced" feature or a trick which would be mostly known and used by experienced developers.

Another benefit is the addition of the this "type", which for generic types would also mean transparently propagating the generic parameter(s) of the current scope to get an even cleaner syntax:

class Process<T> {
 options: {
 priority: number;
 type: T;
 relatedProcesses: {
 parentProcess: typeon this;
 subProcessess: Array<typeon this>;
 }
 }
 constructor(options: typeon this.options) {
 ..
 }
}

Using typeof expression, it would look like this:

class Process<T> {
 options: {
 priority: number;
 type: T;
 related: {
 parentProcess: typeof (new Process<T>());
 subProcessess: Array<typeof (new Process<T>())>;
 }
 }
 constructor(options: typeof ((new Process<T>()).options)) {
 ..
 }
}

I understand the need for a more powerful operator, and using expressions would achieve that, but that wouldn't automatically make it more useful for these cases or for other more specific needs (such as returnTypeOf for example), so I think these are mostly unrelated proposals.

[yortus]

Rotem Dan (@rotemdan) I think most people would write your last example like this:

class Process<T> {
 constructor(public options: ProcessOptions<T>) {
 ...
 }
}

interface ProcessOptions<T> {
 priority: number;
 type: T;
 relatedProcesses: {
 parentProcess: Process<T>;
 subProcessess: Array<Process<T>>;
 }
}

Is it really such a pain point to declare the ProcessOptions interface that a new syntax is needed? Note the other two uses of typeon in your example (inside the options interface) aren't needed at all.

[rotemdan]

Troy Gerwien (@yortus)
You're right, I noticed it when I wrote it but I guess it was shown mostly to demonstrate how something equivalent would achieved specifically with that approach (and specifically for generic classes or interfaces), which at that case wasn't really that much better than just writing the names themselves (although still a bit shorter in some cases, especially for a long class/interface name).

The example in this comment better demonstrates the effect of being able to reference directly into nested anonymous types. With the common approach, every level of the type would need to be declared in its own interface or type alias, so instead of just stating:

state: {
 memoryUsage: {
 real: number;
 virtual: number;
 private: number;
 };

 processorUsage: Array<{ index: number, percentage: number }>;
}

The programmer would need to break it down to something like:

interface ProcessorUsageEntry {
 index: number;
 percentage: number;
}

interface MemoryUsage {
 real: number;
 virtual: number;
 private: number; 
}

type ProcessorID = number; // aliased in case that associated type changes

interface ProcessState {
 id: ProcessorID;
 memoryUsage: MemoryUsage;
 processorUsage: Array<ProcessorUsageEntry>
}

I wouldn't necessarily describe this as a "pain point", maybe something that most programmers feel is necessary as they aren't aware of alternative approaches (when appropriate, of course, I mean, not all cases benefit from this), maybe because this was never expressible in the language, and perhaps not in other ones as well (I'm not aware of other languages with an equivalent feature, but I guess I'm not deeply familiar with that many languages).

[yortus]

Rotem Dan (@rotemdan) fair enough. I guess the deeper the anonymous nesting goes, the less difference in effort there is between

typeon Process.state.processorUsage

and

typeof new Process().state.processorUsage

[benliddicott]

Rotem Dan (@rotemdan) , You are right to identify anonymous types as an important thing to enable.

I think the "typeof expression" approach can handle anonymous types - it's not quite as clean but almost. Instead of:

• typeon Class.prop1.prop2.prop3

You would write one of the following:

• typeof (<Class>{}).prop1.prop2.prop3 with no loss of function. Or alternatively
• typeof new Class().prop1.prop2.prop3

In addition, it could be used in more ways than typeon. For example:

function Blah(): {a: number, b: string}{
return {a: 1, b: ""};
}

// Get the type of the return value.
var b: typeof (Blah());

It would also work to generate the correct type for the return value of a generic function, and so on.

All one has to do is construct an expression of the appropriate type. This can be done by writing an expression casting undefined to the desired type (or writing (new Type()) as Troy Gerwien (@yortus) does) then using the property accessors.

class Process {
 id: number;

 state: {
 memoryUsage: {
 real: number;
 virtual: number;
 private: number;
 };

 processorUsage: Array<{ index: number, percentage: number }>;
 }

 constructor() {
 //...
 }
 //...
}

class OSQuery {
 static queryMemoryUsage(id: typeof (<Process>{}).id): typeof (<Process>undefined).state.memoryUsage {
 return { 
 real: OS.getRealUsage(id), 
 virtual: OS.getVirtualUsage(id), 
 private: OS.getPrivateUsage(id)
 };
 }

 static queryProcessorsUsage(id: typeof (<Process>{}).id): typeof (<Process>undefined).state.processorUsage {
 result: typeon Process.state.processorUsage;

 for (let i=0; i< OS.processorCount; i++) {
 result.push( { index: i, percentage: OS.getProcessorUsage(id, i) })
 }

 return result;
 }

 static queryProcessState(id: typeof (<Process>{}).id): typeof (<Process>{}).state {
 return { 
 memoryUsage: this.queryMemoryUsage(id),
 processorUsage: this.queryProcessorsUsage(id)
 }
 }
 ..
}// Want the type of state.memoryUsage.virtual
// Has type number
var x: typeof ((<Blah>void 0).state.memoryUsage.virtual) = 0;


// want the type of state.processorUsage[]
// Has type {index: number, percentage: number}
var y: typeof ((<Blah>void 0).processorUsage[0]) = undefined;

[yortus]

// Get the type of the return value.
var b: typeof (Blah());

This would be a killer feature for me. This is an easily filled hole in TypeScript's otherwise great type inference abilities.

For instance, suppose you are writing a function, and you want it to take a parameter of a type, say QueryBuilder, that comes from a third-party library you are interoperating with, say Knex. Unfortunately QueryBuilder only appears as a return value from Knex's functions, and is anonymous.

You could make your own interface QueryBuilder {...} and use structural matching. It has lots of properties and methods so that's pretty painful.

You could modify knex.d.ts to expose its private QueryBuilder and submit a PR to DefinitelyTyped (which is what I did in the end).

Or you could write type QueryBuilder = typeof Knex().select(); and hey presto. I would like that very much.

If an anonymous type only appears in a return position, TypeScript doesn't make it easy to reuse it in an input position. In other words, TypeScript lacks an obvious way of expressing "hey this function's parameter has the same type as that function's return value", even though it can definitely do the inference required. typeof could easily express this and more.