Suggestion: Using typeof with an expression

[Andael]

It would be helpful if the typeof keyword were changed to support more complex expressions, such as function calls.

Example

Given the following AngularJS service definition:

module myApp {
  function myApiFactory($http: HttpSvc) {
    return {
      getSetting: (key: string) => $http.get(etc),
    };
  }
  angular.service("myApi", myApiFactory);
}

It would be good if the following statement were possible:

export type MyApi = typeof myApiFactory();

Explanation

Since the function is a factory rather than the actual service, this type alias would other components to have a strongly-typed reference to the service. Though this example relates to AngularJS' service factory and dependency injection, this particular change would not be solely for AngularJS support.

Existing solutions

One option to resolve this issue is to explicitly define an interface for the service. However, this solution would require repeating the signature for all of the service's methods.

A workaround exists that relies on JavaScript's scoping rules to satisfy TypeScript's typeof keyword. However, it significantly reduces readability and clarity. An example:

if (false)
  var obj = myApiFactory(null);
export type MyApi = typeof obj;

[lazdmx]

👍 Seems related to #3749 (comment) as means to get collection element type through expression.

[mhegazy]

I find Using an expression with potential sides effects in a type position really confusing.

[mhegazy]

Also can you elaborate on how the API and the type would be used outside the module?

[yortus]

I have found myself wishing this were possible sometimes - usually when using type definitions from DefinitelyTyped. For example, knex.d.ts internally defines a QueryBuilder interface but does not export it, even though most knex methods return instances of this type. That makes it a pain to, say, write a function that takes a QueryBuilder as an argument.

A workaround is to create a 'dummy' variable with the desired type using an expression that is not necessarily evaluated, and then using typeof on that. In the knex case, the following works:

import Knex = require('knex');
var dummyQueryBuilder = false ? Knex(<any>{})() : null;
type QueryBuilder = typeof dummyQueryBuilder;

The proposal outlined by @ander-nz is far cleaner than this, although I agree with @mhegazy that putting expressions in type positions may be confusing.

The best approach in this example is to fix knex.d.ts and sumbit a PR to DefinitelyTyped, but that's a 'big fix' approach that may not always be possible, and for which typeof expr could provide a nice short-term fix in the meantime.

[yortus]

This would be equivalent of C++'s decltype(expr), which is used in a type position but does not evaluate expr. It's a very useful facility for writing reuseable code that propagates types without foreknowledge of their names (or shapes).

[Andael]

@mhegazy I agree that the syntax could be confusing, as per below:

var a = typeof myApiFunc(); // actually invokes myApiFunc, and then sets a to "object".
type A = typeof myApiFunc(); // does not invoke it, only looks at its return type.

A possible alternate syntax is using <``> brackets, since these are already used by TypeScript. For example:

type MyApi = typeof<myApiFunc()>;

This could simplify the syntax, and would look out of place enough to remind the reader that the expression is a TypeScript feature. Does this look clearer?

[Andael]

@mhegazy And to answer your question about how the type would be used outside the module. That example is designed for AngularJS, which uses dependency injection, such as:

function MyCtrl($scope, myApi: myApp.MyApi) {
    // ...
}

[mhegazy]

i would rather have a compiler operator e.g. __returnTypeof than to overload typeof.

[yortus]

If this facility existed as a purely compile-time thing, say __returnTypeof expr or decltype(expr) or whatever, could it be used in an ambient context? E.g:

declare module "mymodule" {
    import knex = require('knex');
    type QueryBuilder = __returnTypeof (knex(<any>{})()); // obtain the QueryBuilder type from knex;
    export function someExportedFunction(query: QueryBuilder): void;
}

This covers a likely use case for the construct, but would involve allowing expressions to appear in ambient declarations. Is that feasible with the design of the compiler?

[rotemdan]

I think that the scope of typeof expression is very wide. It is very powerful but that also means that expressing some specific patterns in it would require sacrificing tidiness and clarity which would lead to lower general usability in those scenarios.

Perhaps it would be beneficial to try to isolate the most prominent cases where typeof expression would be commonly used (such as, say, typeon or returnTypeOf [and perhaps also returnTypeOn?] ) and try to individually consider a more "optimized", special-purpose syntax and semantics for each one of them.

It would still be useful to have a more powerful operator for special cases, however, it might be possible to emulate many of them by embedding the evaluated expression in a function and "extracting" the inferred return type, like this:

function expressionFunc() {
  return [...] // expression
}
// can also be written as 'expressionFunc = () => [..]'

var x: returnTypeOf expressionFunc;

This would naturally extend to generic expressions as well:

function genericExpressionFunc<T>() {
  return [...] // generic expression
}

var x: returnTypeOf expressionFunc<string>;

[benliddicott]

Can I add my vote to this item. This seems very useful and has wide application.