Proposal: Get the type of any expression with typeof

Working Implementation for this Proposal
Try it out: npm install yortus-typescript-typeof
View the diff: here.
Problem Scenario
TypeScript's type inference covers most cases very well. However there remain some situations where there is no obvious way to reference an anonymous type, even though the compiler is able to infer it. Some examples:
I have a strongly-typed collection but the element type is anonymous/unknown, how can I reference the element type? (#3749)
// Mapping to a complex anonymous type. How to reference the element type?
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));
function checkItem(item: typeof data[0] /* ERROR */) {...}

// A statically-typed dictionary. How to reference a property type?
var things = { 'thing-1': 'baz', 'thing-2': 42, ... };
type Thing2Type = typeof things['thing-2']; // ERROR

// A strongly-typed collection with special indexer syntax. How to reference the element type?
var nodes = document.getElementsByTagName('li');
type ItemType = typeof nodes.item(0); // ERROR

A function returns a local/anonymous/inaccessible type, how can I reference this return type? (#4233, #6179, #6239)
// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(http) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return new MyAPI($http);
}
function augmentAPI(api: MyAPI /* ERROR */) {...}

I have an interface with a complex anonymous shape, how can I refer to the types of its properties and sub-properties? (#4555, #4640)
// Declare an interface DRY-ly and without introducing extra type names
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: typeof MyInterface.prop1.big.complex; // ERROR
}

Why do we need to Reference Anonymous/Inferred Types?
One example is declaring a function that takes an anonymous type as a parameter. We need to reference the type somehow in the parameter's type annotation, otherwise the parameter will have to be typed as any.
Current Workarounds
Declare a dummy variable with an initializer that infers the desired type without evaluating the expression (this is important because we don't want runtime side-effects, just type inference). For example:
let dummyReturnVal = null && someFunction(0, ''); // NB: someFunction is never called!
let ReturnType = typeof dummyReturnVal;           // Now we have a reference to the return type

This workaround has a few drawbacks:

very clearly a kludge, unclear for readers
identifier pollution (must introduce a variable like dummyReturnValue)
does't work in ambient contexts, because it requires an imperative statement

Proposed Solution
(NB: This solution was already suggested in #4233, but that issue is tagged 'Needs Proposal', and there are several other closely related issues, hence this separate issue.)
 This is already allowed for typeof expr in a value position like if (typeof foo() === 'string'). But this proposal also allows an arbitrary expression when typeof is used in a type position as a type query, eg type ElemType = typeof list[0].
This proposal already aligns closely with the current wording of the spec:

Type queries are useful for capturing anonymous types that are generated by various constructs such as object literals, function declarations, and namespace declarations.

So this proposal is just extending that usefulness to the currently unserved situations like in the examples above.
Syntax and Semantics
The semantics are exactly as already stated in the spec 4.18.6:

The 'typeof' operator takes an operand of any type and produces a value of the String primitive type. In positions where a type is expected, 'typeof' can also be used in a type query (section 3.8.10) to produce the type of an expression.

The proposed difference relates to section 3.8.10 quoted below, where the struck-through text would be removed and the bold text added:

A type query consists of the keyword typeof followed by an expression. The expression is restricted to a single identifier or a sequence of identifiers separated by periods. The expression is processed as an identifier expression (section 4.3) or property access expression (section 4.13) a unary expression, the widened type (section 3.12) of which becomes the result. Similar to other static typing constructs, type queries are erased from the generated JavaScript code and add no run-time overhead.

A point that must be emphasized (which I thought was also in the spec but can't find it) is that type queries do not evaluate their operand. That's true currently and would remain true for more complex expressions.
This proposal doesn't introduce any novel syntax, it just makes typeof less restrictive in the types of expressions it can query.
Examples
// Mapping to a complex anonymous type. How to reference the element type?
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));
function checkItem(item: typeof data[0]) {...} // OK: item type is {raw:number, square:number}

// A statically-typed dictionary. How to reference a property type?
var things = { 'thing-1': 'baz', 'thing-2': 42, ... };
type Thing2Type = typeof things['thing-2']; // OK: Thing2Type is number

// A strongly-typed collection with special indexer syntax. How to reference the element type?
var nodes = document.getElementsByTagName('li');
type ItemType = typeof nodes.item(0); // OK: ItemType is HTMLLIElement

// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(http) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return new MyAPI($http);
}
type MyAPI = typeof myAPIFactory(null, 0); // OK: MyAPI is myAPIFactory's return type
function augmentAPI(api: MyAPI) {...} // OK

// Declare an interface DRY-ly and without introducing extra type names
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: typeof (<MyInterface>null).prop1.big.complex; // OK: prop2 type is {anonymous: {type: {}}}
}

Discussion of Pros/Cons
Against: Poor syntax aesthetics. Alternative syntaxes addressing individual cases have been suggested in #6179, #6239, #4555 and #4640.
For: Other syntaxes may look better for their specific cases, but they are all different from each other and each only solve one specific problem. This proposal solves the problems raised in all those issues, and the developer doesn't need to learn any new syntax(es).
Against: An expression in a type position is confusing.
For: TypeScript already overloads typeof with two meanings, as a type query it already accepts an expression in a type position and gets its type without evaluating it. This just relaxes the constraints on what that expression can be so that it can solve the problems raised in this issue.
Against: This could be abused to write huge long multi-line type queries.
For: There's no good reason to do that in a type query, but there are good reasons to allow more complex expressions. This is basically Martin Fowler's enabling vs directing.
Design Impact, Questions, and Further Work
Compatibility
This is a purely backward-compatible change. All existing code is unaffected. Using the additional capabilities of typeof is opt-in.
Performance
Looking at the diff you can see the changes are very minor. The compiler already knows the types being queried, this just surfaces them to the developer. I would expect negligable performance impact, but I don't know how to test this.
Tooling
I have set up VS Code to use a version of TypeScript with this proposal implemented as its language service, and all the syntax highlighting and intellisense is flawless as far as I have tested it.
Complex expressions may occur in .d.ts files
typeof's operand could be any expression, including an IIFE, or a class expression complete with method bodies, etc. I can't think of any reason to do that, it's just no longer an error, even inside  a.d.ts file (typeof can be used - and is useful - in ambient contexts). So a consequence of this proposal is that "statements cannot appear in ambient contexts" is no longer strictly true.
Recursive types are handled robustly
The compiler seems to already have all the logic in place needed to deal with things like this:
function foo<X,Y>(x: X, y: Y) {
    var result: typeof foo(x, y); // ERROR: 'result' is referenced in its own type annotation
    return result;
}

Can query the return type of an overloaded function
It is not ambiguous; it picks the overload that matches the query's expression:
declare function foo(a: boolean): string;
declare function foo(a: number): any[];
type P = typeof foo(0);    // P is any[]
type Q = typeof foo(true); // Q is string

For anyone wanting a quick way to play with this in VS Code with intellisense etc, here is a playground repo.

type P = typeof foo(0);    // P is any[]
type Q = typeof foo(true); // Q is string

I think using types as argument instead of values is a more valid syntax.
type P = typeof foo(number);    // P is any[]
type Q = typeof foo(boolean); // Q is string

It is more clear that the function is not being called, because you provide types and not values as arguments. The other point,  is it is less ambiguous. Some people will use typeof foo(false), whereas some people will use typeof foo(true). If you have types as arguments people can only write typeof foo(boolean).

@tinganho exactly!
Though we still can write typeof foo("abc") with #5185 here "abc" is the singleton string type

@tinganho I've been giving your idea some thought and I see some things I prefer about this proposal, and other things I prefer about your suggestion. Your suggestion is good for the reasons you gave (simpler clearer syntax, less ambiguous, looks less like a function call). The thing I prefer about my proposal is that it doesn't introduce any novel syntax, so does not add any complications to the parser/checker, and it also supports more complex scenarios where you don't have simple type names for the arguments.
I was thinking, what if there was a very shorthand way of writing something like your foo(number) syntax but using the existing expression parsing mechanics? So as an experiment I've introduced a new expression: unary as. You can just write as T and that's shorthand for (null as T). You are basically saying, 'I don't care about the value but I want the expression to have type X'.
With this change (which I've implemented in the playground repo), you can write something much closer to your suggested syntax, but it is still parsed as an ordinary expression:
type P = typeof foo(as number);    // P is any[]
type Q = typeof foo(as boolean); // Q is string

let prop2: typeof (as MyInterface).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

This was just a quick experiment. An equivalent syntax could be (but I haven't implemented this):
type P = typeof foo(<number>);    // P is any[]
type Q = typeof foo(<boolean>); // Q is string

let prop2: typeof (<MyInterface>).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

The second syntax might be called a nullary type assertion, with the expression <T> being shorthand for (<T> null).

@yortus, we spent some time last week talking about this proposal. sorry for not posting earlier. the consensus was 1. we have a problem of not being able to refer to some types, e.g. return of a function or instance type of a class expression. and 2. adding expressions in a type position is not something we are comfortable with.
@tinganho's proposal was one that we talked about as well. i think it is more palatable, though would probably be more complicated to implement. Adding a new unary operator or using cast syntax is not really elegant as just using the type names.

Discussed for quite a while at the slog today. "Accepting PRs" here is "Accepting PRs assuming the implementation doesn't turn out to be too crazy"
@tinganho 's proposal looks pretty good (relative to the other options, at least) and we'd like to see a tentative PR that implements this.
The tricky thing is that we don't want to have a completely separate codepath for resolving the return type of f(number) vs f(0), but the overload resolution algorithm is totally baked-in with the assumption that it's working with a set of expressions rather than a set of types. But we think with a little trickery this should be straightforward.
Basic plan of attack would be:

Expand the grammar when parsing typeof  to allow things that look like function calls, property access, and indexed property access
When parsing the arguments to a function call in a type query (let's call them psuedocalls / psuedoarguments), use the parseType function. This is going to create a TypeNode, but set a flag on the node that indicates that it was a type parsed in the context of a type query
In the checker, checkExpression checks for this flag and calls getTypeFromTypeNode instead of normal expression processing

@mhegazy, @RyanCavanaugh not sure how many corner cases the team discussed, so can I bring up a few here for clarification? I've listed a bunch of examples below and commented each one with what I think should be the result of the typeof operation, with question marks on questionable cases.

Indexer notation
var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number or ERROR?
type Elem3 = typeof data[1+2];      // ERROR or number?
type Elem4 = typeof data[LOBOUND];  // ERROR or number?

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number or number|string?
type Elem5 = typeof tuple[1];       // string or number|string?
type Elem6 = typeof tuple[999999];  // number|string or ERROR?

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // ERROR or number or any?

Function return type notation
// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // ERROR or string[]?

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // ambiguous? or picks first overload?
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // ambiguous? or picks first overload?
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // ambiguous? or picks first overload?

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

Extracting part of a class/interface type
That is, the typeof (<MyInterface> null).prop1.big.complex; examples above.
I take it from above comments that this is out of scope and will not be supported. Is that correct?

Indexer notation
var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number
type Elem3 = typeof data[1+2];      // ERROR, only literals allowed here
type Elem4 = typeof data[LOBOUND];  // number when const resolution is done, otherwise any

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number
type Elem5 = typeof tuple[1];       // string
type Elem6 = typeof tuple[999999];  // number|string

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // number when const resolution work is done, otherwise any

Function return type notation
// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // error, 0 is not a type

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // picks first overload
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // picks first overload
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // picks first overload

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

I'm curious what happens here:
const number = "number";
type Ret3 = typeof f2(number); // What happens here?

@SaschaNaz good question. A similar situation:
class MyClass { foo; bar; }
declare function f(inst: MyClass): number;
type Ret = typeof f(MyClass);     // number (presumably)

In this case it makes sense in typeof f(MyClass) for the MyClass type to be considered before the MyClass value (ie the constructor function). The former leads to Ret = number, the latter would lead to something like error: MyClass is not a type.
Would the same logic apply to a name that referred to both a type and a const value? In your example that would mean the type number would always take precedence over the const value number. Any thoughts @RyanCavanaugh?

Right, we'd resolve this under the usual semantics of a type expression (as if you had written var x: [whatever]). So you could have typeof f(MyClass) referring to invoking f with the instance side, and typeof f(typeof MyClass) referring to invoking f with the constructor function.

So then @SaschaNaz's example unambiguously refers to number as a type, not as the const value, right?
const number = "number";
type Ret3 = typeof f2(number); // Promise<string[]>

@RyanCavanaugh can you confirm that the third group of use-cases is out of scope? e.g. from the OP:
// Declare an interface DRY-ly and without introducing extra type names
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: typeof (<MyInterface>null).prop1.big.complex; // OK: prop2 type is {anonymous: {type: {}}}
}

This use-case (with whatever syntax) will not be supported at this time, is that right?

I thint this should be coverd by allowing this expressions.
   prop2: typeof this.prop1.big.complex;

I think the const thing should be resolved by another typeof.
type Ret3 = typeof f2(typeof number); // typeof number is string so error here

... while this would block typeof data[typeof LOBOUND].

@mhegazy that's a great idea re typeof this. I just realised this already works in the forked implementation I made for this proposal. Well, it works for classes. For interfaces there is no error, but the this type is always inferred as any. Current output from the forked iml:
class MyClass {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is {anonymous: {type: {}}}
}

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is any
}

Is inferring this inside interface declarations a possibility or would this feature remain limited to classes?

I want to make two points about #6179 and Angular
// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(http) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return new MyAPI($http);
}
type MyAPI = typeof myAPIFactory(null, 0); // OK: MyAPI is myAPIFactory's return type
function augmentAPI(api: MyAPI) {...} // OK

The number of parameters can be big. Let's say 15 parameters. At the same time there is no overloads, and it's only the overloads that the parameters in typeof are needed for. So for this case, can we probably think of a syntax like following?

type MyAPI = typeof myAPIFactory(...);

The factory function isn't usually assigned to an own global variable. A function expression is used:

angular.module('app').service('MyAPI', function($http: HttpSvc, id: number) { /*...*/ });

That's what it usually looks like. As can be seen, typeof can't be used here at all.

@thron0 my intuition is that a thing that has more than a few parameters but also returns an anonymous type is going to be very rare. What do you think?

It'll become rare when Angular 1 becomes rare, not earlier.

Basically, what you described is what a typical Angular factory is: "a thing that has more than a few parameters but also returns an anonymous type". It's a function that takes dependencies as its parameters and creates an instance of a service. You could think that a big number of parameters can be a hassle, but the thing is those factories are never called directly. The DI container calls them. The factory is called when something requires its return value (the service) as a dependency. And it's called only once as services are always singletons in Angular. However, a service can be anything, so if we need a non-singleton behavior, the factory can return a constructor (or a factory function). Just like in this code example:
angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(http) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return MyAPI;
});

That's what my current workaround for this situation looks like:
class MyAPI {
    // dependencies (1)
    protected $http: HttpSvc;
    protected id: number;

    constructor(token: string) {...}
    foo() {...}
    bar() {...}
    // Static properties cannot be used with this approach because:
    // 1) this class is a global variable so it can be shared by different
    // instances of the DI container,
    // 2) the id property isn't available here as it's initialized in the subclass
    //// static id0 = id;
}

angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) { // (2)
    return class extends MyAPI {
        $http = $http; // (3)
        id = id;
    };
});

// this type is needed for type annotations in the services that require MyAPI as a dependency
type MyAPIConstructor = typeof MyAPI;

As you can see, it's totally ugly and painful. I have to list the dependencies three times. If I have more dependencies, it's sometimes simpler to write the class in the usual way (inside the factory function) and to declare an interface for its consumers.

Hi, I want to propose to leave the typeof syntax/semantics intact and instead implement a simple type access algebra:
Let's imagine the type syntax extension:
type          ::=  ... |  literalType | type typeAccess | guarded
guarded    ::= "type" id
literalType   ::= stringLiteral | numberLiteral | symLiteral | booleanLiteral
typeAccess    ::= typeField | typeSubscript | typeCall
typeField     ::= "." id
typeSubscript ::= "[" type "]"
typeCall      ::= "(" [type {"," type}] ")"

Each identifier in the scope can be simultaneously bound to the two entities:

compile time type
run time value

the type guard extracts only the former.  Thus
class A {}
a: A

is equivalent to
class A {}
a: type A

in this case if we'd have a class
class ABC {
    a: number;
    b(x: number): string;
    c:string[];
    d:[number, string];
}

then we could write
var a: (type ABC).a; // number
var b: (type ABC).b(number); // string
var c: (type ABC).c[number]; // string
var d: (type ABC).c[0]; // number

It also covers merging type entities and value entities under the same identifier in lexical scope.
interface SAME {
    x: number;
}
namespace SAME: {
    export type x = boolean;
    export var x: string;
}

var a: SAME.x   // boolean
var b: (type SAME).x  // number
var b: (typeof SAME).x  // string

@RyanCavanaugh, @sandersn can you examine this idea?

How do you capture type of expression with your proposal?
On Thu, 19 May 2016 12:26 Anatoly Ressin<EMAIL_ADDRESS>wrote:

Hi, I want to propose to leave the typeof syntax/semantics intact and
instead implement a simple type access algebra:
Let's imagine the type syntax extension:
type          ::=  ... |  literalType | type typeAccess | guarded
guarded    ::= "type" id
literalType   ::= stringLiteral | numberLiteral | symLiteral | booleanLiteral
typeAccess    ::= typeField | typeSubscript | typeCall
typeField     ::= "." id
typeSubscript ::= "[" type "]"
typeCall      ::= "(" [type {"," type}] ")"
Each identifier in the scope can be simultaneously bound to the two
entities:

compile time type
run time value

the type guard extracts only the former. Thus
class A {}
a: A
is equivalent to
class A {}
a: type A
in this case if we'd have a class
class ABC {
a: number;
b(x: number): string;
c:string[];
d:[number, string];
}
then we could write
var a: (type ABC).a; // numbervar b: (type ABC).b(number); // stringvar c: (type ABC).c[number]; // stringvar d: (type ABC).c[0]; // number
It also covers merging type entities and value entities under the
same identifier in lexical scope.
interface SAME {
x: number;
}namespace SAME: {
export type x = boolean;
export var x: string;
}
var a: SAME.x   // booleanvar b: (type SAME).x  // numbervar b: (typeof SAME).x  // string
@RyanCavanaugh https://github.com/RyanCavanaugh, @sandersn
https://github.com/sandersn can you examine this idea?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/6606#issuecomment-220378019

Your example reminds me of that a typeof a dotted expression and type property type #1295 is quite similar proposal. Except one is more static the other one more dynamic.
I like the idea of skipping typeof keyword too.
   prop2: this.prop1.big.complex;

@mhegazy in your example you are using typeof in a this-expression:
prop2: typeof this.prop1.big.complex;

Since we can do this today:
someProp: this;

In my view, an extrapolation of the syntax above for more dotted properties is:
someProp: this.prop1.prop2.prop3;

And not:
someProp: typeof this.prop1.prop2.prop3;

And to just continue with extrapolation why not skip typeof all together?
someProps: foo(number)

why not skip typeof all together?

One reason I can think of is that it would become ambiguous as to whether you are referencing the instance side of a class or the static side:
class C {}

// Does 'x' have the instance type of 'C',
// or does it have the shape of its constructor?
let x: C;

I'd like to reference the type of a property in an interface within another interface, too. Posted my example as #10588 which is now closed in favor of this ticket.
It would be nice to write something like that:
interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<Foo.bar>; // OR: bar: Box<typeof Foo.bar>;
}

which would just translate to this:
interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<string>;
}

Well some of the previously mentioned scenarios can now be expressed with indexed access types (#11929). Just combine this feature with standard typeof expression and you can get something like this:
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: MyInterface["prop1"]["big"]["complex"];
}

and it works! (currently in typescript@next)
I think the next natural thing would be to have something similar but for functions, some "function call types" like this:

interface FunctionLike{
    (arg1 : number, arg2 : string) : {a : number; b : string;}
}

type ReturnType = FunctionLike(number, string); // {a : number; b : string;}

so we could combine it naturally with typeof operator
interface BigThing {
    testString: string;
    testNumber: number;
    testBoolean: boolean;
}

function getSmallThing(thing:BigThing){
    return {
        testString : thing.testString,
        testBoolean : thing.testBoolean
    }
}

type SmallThing = typeof getSmallThing(BigThing) // {testString: string; testBoolean : boolean}

And it looks that this is the syntax that already was proposed at beginning of this thread (@tinganho). :)
But it would be more general feature that just nicely compose with current typeof operator, just like indexed access types do now.
However some questions/doubts still remain:

Will this feature handle some other scenarios like indexed access types do? If won't, is it worth it to implement it?
I assume in most cases it would be nice to not need to specify arguments types at all, since the most common scenario is "I just want to get the type of this one function that doesn't have other overloads'. So maybe introducing some new specific operator for this would be fine (for example typeofreturn or returnof)

Seems like this is technically feasible. It might require refactoring overload resolution / type argument inference so that you don't need to resolve the arguments. I don't think generics poses too much of an additional problem. One question to ask is what happens if no overload matches the call.
I think it is not obvious whether this feature is desirable. If a function returns a very elaborate anonymous type, would it not be more helpful as an author to name the type, so that it does not have to be referenced in this way? I admit this is just based on a stylistic preference. I suppose I am not sure how convenient this will be to use in practice. I think it's fine for the element access though.

type P = typeof foo(0);    // P is any[]
type Q = typeof foo(true); // Q is string

W.r.t. this discussion on allowing parameters to be referred to by their types, I would suggest allowing the same for the actual functions as well.
Context: I'd like to type a function to map over objects:
declare function map<T, F extends Function>(fn: F, obj: T): { [P in keyof T]: typeof F(T[P]) };
The reason I'd like to be able to refer to the function by its type F (aside from just its name fn) would be for cases where its name might be unavailable, e.g. I'd like to be able to say map<T, F extends Function>: CurriedFunction2<F, T, { [P in keyof T]: F(T[P]) }>. Not sure it's a great example (could 'non-functions' with generics like this be expressed at all?), but I hope it illustrates my line of thought for potential use-cases of referring to functions by their type.

Something that would probably be much easier to implement (and still very useful) would be:
const myFunc = () => ({ x: 10 });
type myType = returnof myFunc; // { x: number; }

@dehli That wouldn't work for overloaded functions though. Or generic functions where a type parameter is used in the return type.

@JsonFreeman Couldn't overloaded functions just OR the various return types?  And generic functions could require you to specify the type?

It would be possible, but I'm not sure how useful that would be. It seems like people want something more sophisticated.

I really hope this is gonna be implemented soon as it's a real pain.
As the last workaround does not work anymore I currently use this:
const returnof = <T>(fn: () => T) => null as T

You can check the entire definition file here:
https://github.com/kube/returnof/blob/master/lib/returnof.d.ts
I just created a little NPM package for it, with support for multiple arguments, and function overloads.
You do not need to specify arguments if there's no overload of your function.
const hello = (arg: number) => 'World'

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // string

Overloaded functions
declare function hello(): void;
declare function hello(a: number): number;

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // void

const helloReturnValue = returnof(hello, 42)
type helloReturnType = typeof helloReturnValue // number

If Optional Generics are added like proposed in https://github.com/Microsoft/TypeScript/issues/2175, it will allow a simple declarative-only workaround:
type Return<T extends () => S, S> = S

And use it like this:
type helloReturnType = Return<typeof hello>

@mhegazy @JsonFreeman Any plan on this feature?

Hi everyone,
I have an alternative possible solution to this problem (sorry if it's already been suggested and I missed it) - I proposed it in issue #13949. I didn't know about the typeof operator at that stage, but I think my solution is more general. Basically, introduce a new syntax something like =MyType, which can be used wherever you would use MyType, but instead of declaring the object to be of type MyType, it creates a type named MyType from the inferred type of the object. E.g. this is how I would use it in creating a Vue component.
function createData(){
  return <=MyData>{
    dataProp1: <string>null
  }
}

function method1(){
  let self: MyComponent = this;
  console.log(self.dataProp1);
  self.method2();
}

function method2(){
  let self: MyComponent = this;
  //dostuff
}

type MyComponent = MyData & MyMethods;

let componentOptions = {
  data: createData,
  methods: <=MyMethods>{method1, method2}
}
//todo: register component...

Note the createData function could also by written
function createData(): =MyData {
  return {
    dataProp1: <string>null
  }
}

I found a really fun work around that generalizes to any expression:
const varWithRightType = (false as true) && some.deep.access()
type MyType = typeof varWithRightType;

@johnfn this looks fun for simple cases :), but if your function require some params you have to make additional work around like this:
const stateProps = (false as true) && mapStateToProps({} as any);

I'm using a different work around, that's especially useful for React & Redux, when trying to use type inference to get props type from mapStateToProps function. Then there's no need anymore to manually declare and maintain interface of Props injected by Redux connect which is tedious to maintain and error prone.
This work around will also handle nicely any given function signature for other use cases.
Example of typeof operator "React & Redux" use-case:

Below example try to show a common real-project use-case for usage of typeof operator to derive a type from a function declaration that would be extremely useful if added to TypeScript.

import { returntypeof } from 'react-redux-typescript';
import { RootState } from '../../store';
...

const mapStateToProps = (state: RootState) => ({
  currencies: CurrencyRatesSelectors.getCurrencies(state),
  currencyConverter: storeState.currencyConverter,
});

const stateProps = returntypeof(mapStateToProps);
type Props = typeof stateProps & typeof dispatchToProps;
type State = {};

class CurrencyConverterContainer extends React.Component<Props, State> {
...

Source: https://github.com/piotrwitek/react-redux-typescript-patterns#react-connected-components

@kube's solution and their package https://github.com/kube/returnof seems to work as expected! 👍

Hm. I wish returnof would help type tuple-based map() from a .d.ts file, but given its reliance on the expression language (const declaration, as opposed to staying within the type language), I fear my use-case with that would be more complicated at least.

@tycho01 Yeah I was disappointed that it did not solve the problem.
I already opened a related issue about Optional Generic Types, that I just updated.
#14400

You can generally get the return type of a function via a combination of a dummy ambient function and type inference:
declare function returnTypeOf<RT>(fn:(...rest:any[])=>RT):RT;
var r = returnTypeOf(someFunction);
But if you then want to reuse that return type, then you must capture it ... so we are back where we started:
type RT = typeof r;
It would be so much easier if we just initially extend the concept of typeof to allow returntypeof or even better infer this usage from typeof fn(a,b,c,...), which could then capture different signature return types. This return-type comprehension is already performed by TS internally.
typeofexpression () would be a kind of return-type recursion mixed with type operations: eg
type E = typeofexpression (f(1) + g("x"))
is
type E = typecomprehensionof (typeof f(1) + typeof g("x"))
which might be comprehended like one of
type E = typecomprehensionof (string + string)
type E = typecomprehensionof (string + number)
type E = typecomprehensionof (number + number)
How difficult this internally and the performance costs are unknown to me.

@poseidonCore

Being able to reference the return type of the function argument would be ... bliss ...

I like the current typeof <expression> better, and the return type issue is already covered in #12342.

I was just using typeofexpression and typecomprehensionof as a means of differentiating those usages in the explanation. I would prefer typeof (expression) as the actual syntax.
My point was that comprehending the type of an expression would require comprehending the return type of a function ... f(1) is an expression too. #12342 is related in this way. They are not mutually exclusive.
We can already do typeof for variables and so since an expression is an operation over variables and functions, the next requirement is being able to return the type of a function ... and then comprehend the result based on type rules.

Actually, good point. The issue #12342 wants is a way to access the return type as kind of a property-like thing for generic types, so I misunderstood the relation.

How about using expressions for typeof function calls as in the proposal, but using types in place of parameters?
E.g.
function myFunction<T>(param1: T, param2: string, param3: number): T & {test: string} {
  // ...
}

type ResultType = typeof myFunction({hello: string}, string, number)
// ResultType is: {hello: string} & {test: string}

Note that this doesn't stop anyone from using locally scoped types, by using typeof within the calls, i.e.:
type ResultType = typeof myFunction(typeof obj, string, number)
// ResultType is: typeof obj & {test: string}

This seems a bit better then the original proposal, since it works in an ambient context and seems more flexible in general. To me, it also makes it clearer that we are not actually calling the function, just trying to return the type of its return value.

How I did it for my simple case:
interface IAlertMessage {
  addedAt: number;
  text: string;
  type: "error" | "warning" | "info" | "success";
}

declare let alertMessageInterface: IAlertMessage;

const messages: IAlertMessage[] = [];

function addMessage(text: string, type: typeof alertMessageInterface.type): void {
  messages.push({addedAt: new Date().getTime(), text, type});
}

addMessage("something", "info"); // <- OK - and also has intellisense for the second parameter (after typing first " of the second parameter, press Ctrl+Space in VSCode)
addMessage("something", "fatal"); // <- Compilation error : error TS2345: Argument of type '"fatal"' is not assignable to parameter of type '"error" | "warning" | "info" | "success"'.

The above also works with members of the interface itself:
declare let myIface: MyInterface;

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },
    prop2: typeof myIface.prop1.big.complex.anonymous;
}

The advantage of using declare let ... instead of type ... for me is that it doesn't produce anything in the output .js file.

@varadero this does not solve the problem at hand, which is retrieving the return type of a function call. All you're doing is retrieving the type of a property of a type, which is a supported feature since TypeScript 2.2, I believe.

That's actually the type of a property of a (fake) value. The compiler doesn't let you use typeof with "pure" type or interface, it only works on values.

This would be great to have!

since keyof T[0] already exists, typeof T[0]('something') would work as well?

This would be powerful together with this to refer to this.constructor.

Time for this to happen!

Re-reading this thread, I tried to grasp what we're doing with typeof syntax-wise and why.
Evidently, in the trivial typeof foo case already implemented, it gives the type of foo. (I imagine pet is Fish is immune for using special syntax.)
In my current reading of what this keyword should do in the current proposal, the keyword itself does no more than what it does now, and the current proposal in fact is unrelated to the typeof keyword.
I bring this up because it matters in the case I'd mentioned above, where we're applying a function stored as a type (be it through type or as a generic), rather than as a value.
Given that, I presume that, while typeof fn<A>(string) needs typeof to lift expression-level variable fn for use on the type level, Fn<A>(string), for a function-containing generic Fn however, would not require that, and hence could be 'applied' so as to obtain its appropriate return type here without need for typeof.
In this interpretation, we would check for function calls after any after potential function types: beside typeof fn(...) /typeof fn<...>(...) also Fn(...) /Fn<...>(...), if not even function literal ((foo: Foo) => Bar)(Baz) / + generics. Otherwise, the plan of attack should remain intact.
Maybe I'm misinterpreting how you guys see this, maybe functions stored in types just hadn't even been considered (as I found no mention of them). Either way, I figured it'd be worth confirming.
If announcing function application becomes yet another semantic overload for typeof though, in addition to disambiguating class constructors and lifting expression-level variables to the type level (aside from the expression-level typeof), things seem gradually more convoluted, as already indicated by a few earlier questions in this thread.

@icholy: in short, if the 'function' is in a generic/type, would we still write typeof?

If this is done so it interacts with overloads correctly, it actually gives you "variadic" functions for free (they're just curried instead of having >1 arity), since you can recursively define the return type of a function in terms of the application of one of its overloads, with some base-case overload. This is how things are done in Haskell, and it would be a wonderful feature to have in TypeScript.

@masaeedu: that sounds interesting. And yeah, overloads are definitely what make this proposal so interesting -- they could be used so as to pattern-match over different options, any fallbacks included. Type checks like that so far weren't possible on the type level yet.
I'll concede I've used Ramda more so than Haskell. But from that background, I thought currying normally didn't combine well with variadic functions, as curry would need to 'know' whether to return the result or another function to deal with additional arguments.
Could you perhaps show some pseudo-code as to how you'd see this idea work for variadic functions like Object.assign (skipping over details like & vs. Overwrite as I used in my PoC for R.mergeAll)?

@tycho01 I've been playing around with code like this:
interface Pop<TVarStack extends VarStack> {
    (a: TVarStack["head"]): Pop<TVarStack["tail"]>
}

interface VarStack<THead = any, TTail extends (void | VarStack) = any> {
    head: THead
    tail: TTail
    <TNew>(a: TNew): VarStack<TNew, this>
    (): (a: Pop<this>) => any
}

// Figure out implementation later :)
let stack: VarStack<void, void>;
const pop = stack(new Date())(10)("Bob's")("your")("uncle")()

// a, b, c, d, and e are well-typed
pop(a => b => c => d => e => {
    // Need this because can't figure out how to encode base-case in Pop recursion
    return stack
})

It VarStack is a "variadic" function type in a sense, in that you can give it an arbitrary number of heterogeneous arguments and it will faithfully record the associated type information using recursion at the type level. Unfortunately TypeScript doesn't have good support for transformation and pattern matching at the type level, in the same way that Haskell does.
If we were to have access to typeof, I would be able to solve the base-case problem for Pop, since returnof(overloadedFunction(T)) would essentially give me a way to do pattern-matching at the type level.

@tycho01 I can't do it precisely for Object.assign, because as I said, this only works for curried functions, but I'll try to create a curried assign function for you that works roughly the same way.
I wish they would generalize the type algebra a bit, so that e.g (a: string) => (b: number) => void was just sugar for Func<string, Func<number, void>>, and (a: string, b: number) => void was just sugar for Arity<number, Arity<string, void>>, or something like that. Then we'd just need general purpose tools for transforming types in order to get lots of interesting features emergently.

Apologies all for the triple post. @tycho01 Here's curried, "variadic" assign:
interface Assign<TCurr extends {} = {}> {
    <TAdd extends {}>(a: TAdd): Assign<TCurr & TAdd>
    (): TCurr
}

let assign: Assign = undefined // implement somehow
const result = assign({ foo: "bar" })({ baz: 42 })()

@masaeedu: Hah, so I guess it's like having a reducer function :), though that part could maybe get harder if there were non-variadic (?) arguments as well.
I like the idea; I definitely haven't been thinking in the direction of interfaces quite as much.
If we can change the JS for the typings though, perhaps I'll ask TC39 to just change Object.assign to a non-variadic mergeAll. :D
Not like my increment-based iteration like that actually worked with functions in practice so far though (#17086)... but either way I'm with you this proposal would have a bigger impact than any other I've seen.

@tycho01 I think you're unlikely to get much traction if you ask for arity > 1 functions to be turned into arity 1 functions, since there is an associated runtime cost to curried functions that JS (or at least existing JS engines and code) is probably not highly optimized for. I think what we need instead is for TypeScript to make it equally easy to build up and deconstruct types for arity > 1 functions recursively. I guess this all comes back to #5453.

Others may find it interesting to learn that c++ has a very similar feature: decltype(expression)

Is this feature ever going make it to TypeScript?
I highly prefer the original proposed form where the argument is an expression, but TS team's intention to have special syntax with types in expression positions just complicates everything and delays from landing it into the language.
We need to keep this topic up.

I'd be really glad if we could get even a subset of this proposal implemented. Namely, this single one:
type A = typeof anotherVariable . I could do everything with just this one line. interface B extends A, <B & A> : B & A, etc.
I'm seeing a lot of use-cases for this sort of thing with React. When you create higher order component, it's much harder to hint to the component class declaration that it's currently a HOC.
What I ended up doing is creating two classes. One class extends React.Component and adds all the additional methods, while the class inside of the HOC function manipulates the render().

@blindbox type A = typeof anotherVariable does work already:
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));

function checkItem(item: typeof data) {
    // item is Array<{ raw: number; square: number; }>
}

@Igorbek Wow, you're right.
Okay, I figured out why it didn't work on my end.
This won't work
const typeTest = (type: any) => {
  return 1 as any as App & B
}
type A = typeof typeTest(1)

This however, will work.
const typeTest = (type: any) => {
  return 1 as any as App & B
}
const typeTestVal = typeTest(1)
type A = typeof typeTestVal

Yeah, so the problem is that it cannot be used in certain use cases, such as when you need to use generic type arguments.
function someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item: T) { ... }

// it impossible to work this around because there's no chance to create a fake variable that would be parameterized by T
function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

@Igorbek:

I highly prefer the original proposed form where the argument is an expression, but TS team's intention to have special syntax with types in expression positions just complicates everything and delays from landing it into the language.

So since they wrote that, we've gotten literals for strings and numbers, meaning things are getting a bit fuzzier -- those would work either way. Literal array and objects similarly look similar to their type notations, so so far so good.
So then we also have stored values/types, e.g. variables, generics, other types. For things to get useful, we shouldn't just have to settle for part of these here.
What makes a good argument for their type-based approach here is that allowing this mixture sort of comes for free at the type level. That is to say, at the type level we could already do say typeof myVar, meaning if this function 'application' is added to the type level, we'd automatically be able to plug in both stored types and regular variables.
I'd be interested to see your further thoughts on the originally suggested approach. Admittedly, that might serve as to expose a bit more to the type level: JS-based operators (think ! && || + - * / instanceof) as well as TypeScript specific operators (assertion operator !).
The thing about those JS operators is like... they're pretty useless at the type level as it stands, as allowing them to operate on literals to yield the corresponding literal result types is currently deemed out of scope (ref) -- expression-level 1 + 1 just yields type number, and similar for the others.
With this in mind I've kinda been down with their type-based proposal myself.

Is this feature ever going make it to TypeScript? [...] We need to keep this topic up.

I suggested this proposal as a more general solution to a smaller symptom here, though to limited success.

@tycho01 My arguments for expression-based variation of typeof are almost the same as originally stated by @yortus:

consistency: existing typeof (in type position) is already working with expressions, however constrained to accept a single symbol. So that accepting types or pseudo-calls would introduce much more cumbersome syntax that is much more another syntax branch (in addition to expressions and types).

users do not need to learn new syntax

simplicity: TypeScript seems to already have all facilities required to implement this feature in the unobtrusive way (it's been proven by the PR)
completeness: expressions are at least have the same expressiveness as types, as we can always use type assertions ((undefined as any as <any arbitrary type can be here>)), but sometimes type system lacks types that can however be expressed in expressions (spread and rest types were introduced after the corresponding expressions had been landed).

Thank you @tycho01 that you brought that point to promised PR (I actually came here after your comments there), that really shows how such a simple and generic feature can cover much more complex scenarios in very elegant way without baking in very specific behavior into the language.
I see the extended typeof as a real game changer for type system expressiveness, most like mapped types/keyof did that.

@Igorbek: Thank for elaborating, I see where you're coming from then. Perhaps these two approaches serve different use-cases then.
I think you're better demonstrating today's value of the original proposal than the original post does today, as current TS (or, well, Playground's 2.3.3) can make many of the original scenarios work already:
// I have a strongly-typed collection but the element type is anonymous/unknown, how can I reference the element type? (#3749)

// Mapping to a complex anonymous type. How to reference the element type?
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));
declare function checkItem(item: typeof data[0]): any
// ^ no longer errors, needs no further change

// A statically-typed dictionary. How to reference a property type?
var things = { 'thing-1': 'baz', 'thing-2': 42 };
type Thing2Type = typeof things['thing-2'];
// ^ no longer errors, needs no further change

// A strongly-typed collection with special indexer syntax. How to reference the element type?
var nodes = document.getElementsByTagName('li');
type ItemType = typeof nodes.item(0);
// ^ the `.item` access works, but function applications still errors, would be fixed by either version of the proposal.

// A function returns a local/anonymous/inaccessible type, how can I reference this return type? (#4233, #6179, #6239)

// A factory function that returns an instance of a local class
function myAPIFactory($http: /*HttpSvc*/any, id: number) {
  class MyAPI {
    constructor(http) {}
    foo() {}
    bar() {}
    static id = id;
  }
  return new MyAPI($http);
}
declare function augmentAPI(api: MyAPI /* ERROR */): any
// ^ dunno how this fits into the proposal, MyAPI isn't exposed on the expression level either

// I have an interface with a complex anonymous shape, how can I refer to the types of its properties and sub- properties ? (#4555, #4640)

// Declare an interface DRY-ly and without introducing extra type names
type MyInterface = {
  prop1: {
    big: {
      complex: {
        anonymous: { type: {} }
      }
    }
  },
  // prop2 shares some structure with prop1
  prop2: MyInterface['prop1']['big']['complex'];
}
// ^ no longer errors after swapping `.k` access to `['k']`. `typeof` was unnecessary and counter-productive -- MyInterface isn't exposed on the expression level.

I guess these examples are no longer making much of a case for either the expression or type approaches -- most are obsolete, and trivial function application would be enabled by either.
Admittedly type-level based function application, as focused on by tinganho, the TS team and myself can expose expression variables through typeof, though as you noted, the type level admittedly tends to lag behind the functionality exposed on the expression level. This function application itself as well as the spread syntax you mentioned are obviously primary examples, and I'd definitely love to see them addressed. Perhaps much of the current gap could even be tackled here.
Similarly, an expression-first approach would also allow injecting types using <MyType> whatever or whatever as MyType, though as the typeof in the type approach, it would similarly seem like an afterthought: questions about applying functions stored in types/generics remain, which likely make up for most of the actual added value of that type-based approach (though unmentioned there) -- accurate inference for higher-order functions, as well as say type-based conditionals like in that promised thread.* Worse yet, unlike the OP's use-case, these have no work-arounds.
I think see where the ideas clash -- current proposals have contradictory views on whether the typeof keyword would switch its expression to the value level, vs. (in my interpretation) leaving typeof as-is, but exposing function application syntax on the type level.
In my view, the contradiction is somewhat accidental though. I wouldn't disregard the legitimacy of either use-case; if both were to be implemented I could see an extra keyword avoiding semantics clash.
*: I just realized you'd probably go about higher-order functions by referencing functions in parameters by their parameter names, rather than by capturing their types in generics.
It looks like things can in fact be converted in both directions: typeof helps lifting from the value level to the type level, while declare let y: x; helps lift things from the value level to the type level. Inelegant like the OP's workaround, but yeah.
If function types were brought in through e.g. explicit generics though, I guess this would not help -- they'd be on the type level without a way to move them over.
If that sounds like I'm pre-emptively hoping to cover bases on functionality, it's probably because much of my progress on unsolved typing challenges got blocked on this one add-on (with notable mention to 5453). But if we can figure these things out, it'll be worth it.

@Igorbek I don't understand what you expect with this snippet:
function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

@masaeedu sorry, I meant:
function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(undefined as any as T)) { ... }

Just to elaborate, that is what currently cannot be worked around by introducing a fake variable:
declare const _typeofItem = someFunctionWithComplexReturnTypeThatUsesGenerics<T>(undefined as any as T); // no T here
function use<T>(item: typeof _typeofItem) { ... }

BTW, just realized that current proposal conflicts with member type query type operator T[K] since typeof has higher priority:

typeof x[K] currently means (typeof x)[K] where K is a type
if the expression-based variation is taken, an ambiguity would be introduced:

typeof x[k] means (typeof x)[k] where k is a type; or
typeof x[k] means typeof (x[k]) where k is an expression

I would actually prefer typeof (x[k]) because they are semantically equivalent, but is a breaking change for sure.

When I used Chrome's developer tools, I got that the member type has higher priority. Where did you find that?

@Igorbek: yeah, that appears to be why that type Thing2Type = typeof things['thing-2']; from the original post works already.

@dehli: you're comparing JS expression level to TS type level -- they're not the same. One runs in browsers/node, the other in the TS compiler.

I personally find it odd that TypeScript resolves type-level typeof with a higher precedence than indexed type access. It almost looks like a bug to me, honestly. (I wonder if that case is actually tested.)

@tycho01 Gotcha. I assumed TS would use the same order of precedence as JS.

@dehli the expression levels are the same, yeah. On the type level it's another thing with similar syntax, but returning a type instead of a string.
I'm guessing the precedence might be the result of the limitations they'd envisioned for it to have. I'll concede those considerations may no longer seem as sensible if its function is to be expanded.
On another note, if both versions of the proposal were to be implemented, the brackets would serve as an effective way to keep it explicit what level we'd be in for that as well. I'm having trouble coming up with things that don't sound like compromises, but yeah.

@Igorbek Is this the primary remaining use case for typeof on expressions? If we get #14400, that would give us returnof using plain user-defined types if I'm not mistaken.

#14400 won't give us returnof in its generic form:
type Return<T extends () => R, R = any> = R;

// overloaded function
declare function f(item: number): number;
declare function f(item: string): boolean;

type fType1 = Return<typeof f>; // ??
type fType2 = typeof f(1); // number
type fType3 = typeof f('a'); // boolean

// generic function
declare function g<T>(item: T): T;

type gType1 = Return<typeof g>; // ??
type gType2 = Return<typeof g<number>>; // not supported syntax
type gType3 = typeof g(1); // number
type gType4 = typeof g<number>(1); // number
type gType5 = typeof g('a' as 'a'); // 'a'

I'm not aware of all the remaining use-cases, they seem not yet been discovered yet, but the most unbeatable and attractive to me are:

conditional mapped types that are much more powerful that we could get with #12424, because typeof would use standard overload resolution; @tycho01 has shown an elegant example in promised types PR #17077
getting types of function/method returns in context of generic types (as I showed before)

@masaeedu: Good question. The short version is pretty much what @Igorbek said; for a bit more detail of concrete challenges solved, you'll find a short list at my 'top features needed' list in #16392, where I've tried to tie unsolved challenges to the proposals that could enable them.
This includes:

Given known inputs you can suddenly calculate the exact return types for things like reduce / map / filter / find -- anything involving iteration and checks. stdlib.d.ts would benefit there, and so would FP libs like Ramda/Lodash. In practice not all inputs may be known (more list-like arrays than tuples), but map and filter operations on objects could be typed better than just Partial as well.
Currently function composition typings are not able to take input-dependent return types into account either.
It would suddenly also make it viable to start typing things like lenses.
It also enables:
operating on boolean literals at the type level, which has so far been impossible
unwrapping types for flatMap-like operations such as that promised proposal
adding constraints to type/function input, the topic of #15347 and an idea I got from book 'Type-driven development with Idris' on dependent types. This could help to say disallow 0 divisors -- essentially a hack to subtract from types, the topic of #4183. I'm sure I haven't imagined most use-cases there yet, but that could be done with this, e.g. function div<B extends number, NotZero = { (v: '1') => 'whatever'; }({ (v: 0) => '0'; (v: number) => '1'; }(B))>(a: number, b: B). Normally Idris language advertises with length-safe vector/matrix operations, but that only needs this for higher-order functions.
given #5453 as well, this also helps type functions such as curry, Function.prototype.bind, Promise.all (not an exhaustive list, just some functions other people raised as challenging).
switch logic proposed in #13500, here resolved through function overload pattern matching
those mapped conditional types that are the topic of #12424 and #17077

@Igorbek's proposal of an expression-first approach would (at the cost of maybe breaking some unknown applications of part of the above list -- I've yet to think of anything concrete) additionally promises closing the gap between value and type levels, which currently include things like this function application, spread/rest, assertion operator !, union type subtraction through type guards, and possibly more I can't think of off the top of my head.
I guess this whole trade-off raises some questions like why make all the same functionality accessible in two ways (actual type level, expression level accessed embedded in type level).

@tycho01 Thanks for the list; there's a lot of links in there that I need to digest. I really want pattern matching on types as well, and #6606 is a good, pragmatic solution to the problem. However it seems to me that there is an increasing confusion between things at the value and type levels, and #6606 will not improve things in this area.
The reason this feature is needed is because we have no way of constructing type expressions that correspond to:

the return type of a function type, when applied with arguments of certain types
(before typeof K[L]) the type of a property on an object type that corresponds to a key of a string literal type
(possibly others, I need to go over your list more closely)

I feel like it should in fact be possible to construct purely type level expressions for these, without resorting to mixing together value-level constructs and type-level expressions. It would be nice if types like (a: A) => B or A | B were sugar on simple parametrized types like Func<A, B>, Union<A, B>, and we had general tools for manipulating parametrized types (HKTs, fundeps or type families, etc.).

I feel like it should in fact be possible to construct purely type level expressions for these, without resorting to mixing together value-level constructs and type-level expressions.

Oh, yeah, I personally didn't really intend to resort to using value-level constructs at all -- this is all I'm trying. If the value level were indispensable, I might have been in the expression-based camp here myself. :P
I guess the gap between value and type levels is mostly expected to narrow (does TC39 move faster than TS?), and afaik the gaps do have outstanding type-level proposal already (see the bottom of my previous post).
Heck, I realize constructing typings for quite some of the functions is gonna be outside the experience of most users.
The way I look at this is, I want the standard library and FP libs to be typed so well that TS users could just write those and have inference automatically taken care of for them.
TS has only a few type-level operators, but solving actual problems with them (prime example is #12215's Overwrite / Omit) might well seem little short of rocket science to casual web devs. Heck, it's taken us until recently too, and they're not even prototype / index / symbol -proof yet.

It would be nice if types like (a: A) => B or A | B were sugar on simple parametrized types like Func<A, B>, Union<A, B>

We can flip it around and create the parameterized types as aliases / type constructors. To a type operation taking a Foo<Bar>, it doesn't matter whether your thing simplifies to one -- it just checks whether it fits the description.
This is pretty much what stdlib.d.ts does -- you have a foo[], but it satisfies the Array<Foo> description and therefore works with its Array.prototype typings.
Not like that actually helps though:
type Union2<A, B> = A | B;
type TuplizeA<Tpl extends Union2<any, any>, A, B> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type a = TuplizeA<1 | 2>;
type TuplizeB<Tpl extends any | any> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type b = TuplizeB<1 | 2>;
type TuplizeC<Tpl extends Union2<A, B>, A, B> = [A, B];
type c = TuplizeC<1 | 2>;
// ^ need 3 arguments, maybe fixable with #14400
type TuplizeD<Tpl extends A | B, A, B> = [A, B];
// ^ need 3 arguments, maybe fixable with #14400
type d = TuplizeD<1 | 2>;

So um yeah, haven't solved it but just realized kube's #14400 could actually help there. And I just saw you there earlier today too!
Same thing for functions actually -- which is a good reminder that #14400 might not just do function return types there but param types as well.
This approach would for the moment need to use overloads, which is unfortunate since it doesn't scale, but yeah. To make it generic again, we'd essentially use these #6606 pattern-matching overloads to trigger the right option for different arities.
I suppose one could use that to generically convert them into tuple types, then iterate over them using my increment approach to do operate on them somehow.
For unions I'd been hoping for a prettier way to convert to tuple types. It'd add an arbitary order though, and can't think of a pretty syntax/keyword either.

One related topic so far left untouched here has been how to provide this bindings in this type-level function 'application'. Now, JS delegates overwriting this to the Function.prototype methods, but as it stands, those lack a way to handle this at the type level.
Random example syntax, given a function type F (this: Foo, a: number, b: string) => SomeReturnType that might otherwise have been invoked as F(MyA, MyB): F(this: MyFoo, MyA, MyB).
Calculating the return type without overwriting the this binding would still be like F(MyA, MyB), mirroring how the type-level this argument normally gets ignored if you try to use such a function at the expression level.
Pros of this example syntax:

mirrors the declaration syntax

Cons of this example syntax:

mirrors the declaration syntax

So, turns out, this is already in the language!
Don't get too excited.
@DanielRosenwasser just pointed me to #12146, a bug that allows function calls on literals to be used in place of types.
5 minutes later
Ta dah! A horrible evil thing we should never use in production. But it's tempting...
interface String {
    passthrough<T>(v: T): T;
}

// All work
type ANumber = "".passthrough(10 * 10);
type AString = "".passthrough("hello" + "world");
type AHelloWorld = "".passthrough("hello world");
type AnArbitraryThing = "".passthrough(Object.assign({hello: "world"}, {foo: "bar"}));
type ThisCraziness = "".passthrough((() => "cows are big dogs"));

That makes the Effort: Difficult on this issue look a little dubious, looks like they did it by accident over there.
Have fun @tycho01.

@TheOtherSamP I tried this with TypeScript 2.4.2 and all of the those types are inferred to be any.

@pelotom Huh, it's working here on 2.4.2 and 2.5.0-dev.20170803. Target es6 and and strict mode.

Looks like they've just fixed it though, I fear that may be my fault. #17628

@TheOtherSamP Nope, no dice. Oh well.

@pelotom That's strange, it's working in a completely fresh project for me, I don't know what would be different about our setups.

@TheOtherSamP: haha, that's pretty funny.
Time-wise looks like they started the fix there a bit before your comment though. Oh well.

That makes the Effort: Difficult on this issue look a little dubious, looks like they did it by accident over there.

They were referring to a type-based implementation, which would mean some changes, while this seems to use expression language (-> +, Object.assign, further function calls).
@pelotom:

I tried this with TypeScript 2.4.2 and all of the those types are inferred to be any.

His snippet seems to work in Playground (2.3.2). On a recent-ish version outside of it (^2.5.0-dev.20170626) I'm having trouble reproducing too.
I imagine @Igorbek won't be happy.

@tycho01 I think it all got started by my drawing attention to it in #17618. Oh well, that'll teach me to semi-seriously consider using it in production.

They were referring to a type-based implementation, which would mean some changes, while this seems to use expression language (-> +, Object.assign, further function calls).

 It's a shame, that probably is a better version of the feature, but I wish we could have it now. I push the limits of the type system a lot, and either this or #12424 would open up so many options.

Opened a PR at #17961.

@yortus Does this cover case of 'typeof literal'?
TypeScript today doesn't allow to write "const x: typeof 1 = 1;"

@NN--- the original proposal covers all expressions, but as I understand it the 'approved' part only covers property access and function return types.
Even if typeof 1 was allowed, I'm not sure whether it would give the literal type (1) or the wider type (number).

TypeScript today doesn't allow to write "const x: typeof 1 = 1;"

Why not const x: 1 = 1;?

@SaschaNaz I wanted to write something like
const a = {q:1};
const b = {q:1};
const x: ReadonlyArray<typeof a> = [a,b];

But similar doesn't work with literals:
const x: ReadonlyArray<typeof 1> = [1,2,3];

@yortus Good point about exact type. Didn't think about literal types..

@NN---: I believe your example works already.

@tycho01 Flow now have $Call type to get return type of function https://github.com/facebook/flow/commit/ac7d9ac68acc555973d495f0a3f1f97758eeedb4

Wouldn't allowing only typeof fn(...) be the same as allowing typeof of arbitrary expressions?
function fn() {
  return /** whatever expression you like */;
}
type a = typeof fn();

Not really. You're doing a type evaluation of an expression, not an execution of the expression.

@dyst5422 typeof fn() wouldn't actually evaluate the expression, it would just give you the return type.

@dyst5422 , as @pelotom said, I didn't mean that you would execute the function. To elaborate more: if you don't allow the typeof of arbitrary expressions but you allow typeof the return type of a function, what I will do to figure out the type of more complicated expressions is to wrap them in a function so I can ask for its return type. That creates a function at runtime though just to get it's return type, and it's more boilerplate to write.

Ah, I follow now. Yeah, I think the preferable way to go would be to be able to use it as
type TypeOfExp = typeof (
  false &
  "false" &
  0
)

to be able to arbitrarily do expression type evaluation

Will it be possible to query the return type of a new invocation?  My use case: I want to write type annotations for a function that accepts a reference to any PromiseConstructorLike implementation (e.g. $q or Bluebird) and returns a Promise constructed by that implementation.
declare function wait<P extends PromiseConstructorLike>(time: number, implementation: P): typeof new implementation<void>((res: any, rej: any) => void);

const bluebirdPromise = wait(1e3, Bluebird);
// typeof bluebirdPromise should be instance of Bluebird

Will it be possible to query for return types without typeof, or will we have to null as FnType?
interface Fn {
    (a: string): string;
    (a: number): boolean;
}
type Ret = Fn(number); // Ret = boolean
type Ret = typeof (null as Fn)(number);

Sorry if these questions have already been answered; I couldn't find them.

Whats the point of new here, wouldn't you just want typeof implementation()?

No, because implementation() is not a valid call.  PromiseConstructorLike can only be invoked via new, per its type declarations.  typeof implementation() is a type error, just like (typeof implementation)['foobar'] would be a type error.
Playground link

Is it possible to introduce inferable generic types like what FlowType did? At least, it can solve the problem for getting the type of return value of functions.
type _ExtractReturn<B, F: (...args: any[]) => B> = B;
type ExtractReturn<F> = _ExtractReturn<*, F>;

@Cryrivers: see #14400 for that approach. It doesn't actually solve the problem where the output type depends on the input though.

Ended up needing this again today to hint what a call to a function would return dynamically, sure wish it would get priority.

A ReturnType<T> operator is being added to lib.d.ts in TS 2.8, powered by conditional types.

As ReturnType<T> has yet to take into account return types dependent on argument types, for reference, here is Flow's $Call type implementation.

I updated my earlier post of use-cases of this proposal (or its type call interpretation) based on the recent TS additions.
Pattern matching use-cases are now covered by #21496, leaving... the cases where we wanna calculate types based on lambdas provided by the user, e.g. curry, function composition, map, reduce, lenses editing based on a lambda... the fun stuff. :)
P.S. @thorn0: I think your Angular use-case can be filled with ReturnType (#21496) now!

I thint this should be coverd by allowing this expressions.
prop2: typeof this.prop1.big.complex;

@mhegazy Is there a separate issue for tracking this ?
It is annoying that typeof works for locals but not for properties, while working for static properties.
class A {
 x:number;
 static y: number;
 f() {
  const a = 1;
  const b: typeof a = 2; // OK
  const c: typeof this.x = 3// No :(
  const d: typeof A.y = 4 // OK
 }
}

@NN you can always use indexed types for this:
this['x']

@cameron-martin Doesn't work. [Playground](http://www.typescriptlang.org/play/#src=class A {
    x%3A number%3B
    static y%3A number%3B
    f() {
        const a%3A number %3D 1%3B
        const b%3A typeof a %3D 2%3B %2F%2F OK
        const c%3A typeof this.x %3D 3%3B %2F%2F No %3A(%0D%0A%20%20%20%20%20%20%20%20const%20d%3A%20typeof%20this%5B'x'%5D%20%3D%203%3B%20%2F%2F%20No%20%3A(%0D%0A%20%20%20%20%20%20%20%20const%20e%3A%20typeof%20A.y%20%3D%204%20%2F%2F%20OK%0D%0A%20%20%20%20%7D%0D%0A%7D )

@tycho01 the new type infering and conditionals are awesome, but also super annoying that they don't work for function overloading. The reason given was it needs something like this typeof to resolve the function type out of the possible ones.

@NN just use const d: this['x'] = 3;

Oh, nice :)

@NN--- or use
class A {
    x: number;
    static y: number;
    f() {
        const self = this;
        const a: number = 1;
        const b: typeof a = 2; // OK
        const c: typeof self.x = 3; // OK
        const d: typeof self['x'] = 3; // OK
        const e: typeof A.y = 4 // OK
    }
}

@tsofist I am aware that local works, but I find this ugly.
It is same as manual saving 'this' for 'function(){}' callback instead of using lambda with implicit capture.

@NN

this ugly.

yep, this is just an option :)

Conditional types now make this largely irrelevant since you can write ReturnTypeOf<T> along with specific other aliases if you want to validate a particular set of arguments. They can't do overload resolution but we don't think this feature is worth the complexity just for that use case.

@RyanCavanaugh I believe you mean ReturnType<T>?

@RyanCavanaugh that is unfortunate - the overload resolution is what I really needed. Is there another issue to track adding overload resolution to conditional / infer types?

You should be able to write it:
type Return1<A1, T extends (a: A1) => any> = T extends (a: A1) => infer R ? R : any;
type Return2<A1, A2, T extends (a: A1, a: A2) => any> = T extends (a: A1, a: A2) => infer R ? R : any;

declare function something(a: number): number;
declare function something(a: string): string;
declare function something(a: number, b: string): boolean;

type A = Return1<number, something>; // number
type B = Return1<string, something>; // string
type C = Return2<number, string, something>; // boolean

I haven't tested it though, and you would need a separate helper for each number of args.

@ForbesLindesay: the something is currently an expression-level variable -- referencing it with e.g. typeof here (or declaring it as an interface) fixes that. I'm not actually managing to get it to yield appropriate return types though (on 2.8.0-dev.20180318).

@ForbesLindesay unfortunatly I don't believe that works; the infer mechanism will choose the last method overload:
type Funcs = ((p1: string, p2: string) => void) & ((p1: number) => void);

type FuncPromise1<T> = T extends (p1: infer P1) => void ? (p1: P1) => Promise<[P1]> : never;
type FuncPromise2<T> = T extends (p1: infer P1, p2: infer P2) => void ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: FuncPromise1<Funcs> & FuncPromise2<Funcs>;

However, the infer mechanism is able to deal with tuple unions:
type Tuples = [string, string] | [number];

type TuplePromise1<T> = T extends [infer P1] ?  (p1: P1) => Promise<[P1]> : never;
type TuplePromise2<T> = T extends [infer P1, infer P2] ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: TuplePromise1<Tuples> & TuplePromise2<Tuples>;

maybe we need something to allow overload -> object, and function -> object, unwrapping. Do the type mapping and inference there, then wrap back up to a function and overload.

@MeirionHughes:

maybe we need something to allow overload -> object, and function -> object, unwrapping. Do the type mapping and inference there, then wrap back up to a function and overload.

Like (a: number, b?: string) => boolean -> { a: number, b?: string }? We can't get param names yet like that, but conceptually this gets tougher for rest params ((a: number, ...b: string[]) => boolean), also since we can't use object types to do order.
Order probably matters more than names, and we can convert between params and tuples. Spreads/optionals may still complicate it a bit as well.
This reduces the problem to extracting the overloads. Overloads should be an intersection of function types like ((a: number) => 123) & ((s: string) => 'hi'), so then the problem is how to 'unwrap' an intersection type (into e.g. a tuple type) -- as of now, we don't have that.
I find this path unsatisfying as it'd address the overload use-case yet not say generics, but yeah. Intersection unwrapping was still a gap either way.

Since this issue is now closed, is there a new proposal yet for the parts that are still missing? Like a way to deal with return type depending on arguments?

Since this issue is now closed, is there a new proposal yet for the parts that are still missing?

none that i am aware of.

Like a way to deal with return type depending on arguments?

do not think we have an issue tracking call types.

Is there preliminary support for the idea of just adding type level function application? I could write up a proposal for that. Syntactically I think that's the easiest path.
type MyType<A> = {
    foo: A
}

type Wrap = {
    <T>(maybe: MyType<T>): MyType<T>;
    (maybe: any): MyType<any>;
}

type Naive = ReturnType<Wrap>; // Naive = { foo: any }
type Proposed1 = Wrap(maybe: number); // Proposed1 = { foo: number }
type Proposed2 = Wrap(maybe: MyType<number>); // Proposed2 = { foo: number }
type Proposed3 = (<T>(maybe: T) => MyType<T>)(maybe: number) // Proposed3 = { foo: number }

Edge cases:
const foo = <T>(a: T) => T:

type Edge1 = (typeof foo)(a: number) // Probably trivial?

type Foo = {
    <T>(a: string): T
}

type Edge2 = Foo<number>(a: string) // Should this be allowed? Probably not, because:

type Bar<A> = {
    (a: string): A
}

type Edge3 = Bar<number>(a: string) // Things are getting strange

interface Baz<A> {
    <T>(a: T): T | A
}

type Edge4 = Baz<number>(a: string) // What is this?

Is there preliminary support for the idea of just adding type level function application? I could write up a proposal for that. Syntactically I think that's the easiest path.

Not at the time being. We really do not want to put overload resolution in higher-order-type space; the process is rather involved, and includes multiple passes to infer type parameters, and contextually type arguments, etc.. doing this in higher order is first a lot of work, and second will pose performance challenges that we are not prepared to handle at the time being.

@mhegazy has the team's stance on this changed at all, given the recent work in #24897 ??
There seems to be quite a few issues around whose solutions could be reduced to a $Call type, and a $Call type would open the door to a relatively straightforward way of emulating higher-kinded types; see https://gist.github.com/hallettj/0fde5bd4c3ce5a5f6d50db6236aaa39e for example (replace the use of $PropertyType and $ObjMap with $Call).
Such a feature would arguably be in line with TypeScript's track record of finding a reasonable common solution to many problems, no?

Conditional types now make this largely irrelevant since you can write ReturnTypeOf<T> along with specific other aliases if you want to validate a particular set of arguments. They can't do overload resolution but we don't think this feature is worth the complexity just for that use case.

@RyanCavanaugh @mhegazy
I agree that it is possible to do things using conditional types. I think that it would not bring much additional complexity in the compiler if we would rewrite User.avatar to User extends { avatar: infer T } ? T : never? So for example we could write
export type Avatar = User extends { avatar: infer T } ? T : never;

as
export type Avatar = User.avatar;

to improve readability.
Full example
Suppose we load and transform some data, and end up with a function findUser like this
export function findUser() {
  return {
    username: 'johndoe',
    avatar: {
      lg: '1.jpg',
      s: '2.jpg'
    },
    repos: [
      {
        name: 'ts-demo',
        stats: {
          stars: 42,
          forks: 4
        },
        pull_requests: [
          { date: '2019-08-19', tags: ['bug', 'agreed-to-cla'] },
          { date: '2019-08-10', tags: ['bug', 'includes-tests'] },
          { date: '2019-08-07', tags: ['feature'] }
        ]
      }
    ]
  };
}

Thanks to the inference from mapped types, we can extract the type from the function like so:
export type User = ReturnType<typeof findUser>;
export type Avatar = User extends { avatar: infer T } ? T : never;

Suggestion: this should evaluate to the same thing
export type Avatar = User.avatar;

Additionally, we could even assert that User.avatar must not be of type never.
More examples
export type Repositories = User extends { repos: infer T } ? T : never;
export type Repository = User extends { repos: (infer T)[] } ? T : never;
export type RepositoryStats = Repository extends { stats: infer T } ? T : never;
export type PullRequests = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type PullRequest = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type Tags = PullRequest extends { tags: infer T } ? T : never;
export type Tag = PullRequest extends { tags: (infer T)[] } ? T : never;

export type Repositories = User.repos;
export type Repository = User.repos[];
export type RepositoryStats = User.repos[].stats;
export type PullRequests = User.repos[].pull_requests;
export type PullRequest = User.repos[].pull_requests[];
export type Tags = User.repos[].pull_requests[].tags;
export type Tag = User.repos[].pull_requests[].tags[];

When mapping a nested property in one go, it is not very clear what is happening
export type Tag2 = User extends { repos: { pull_requests: { tags: (infer T)[] }[] }[] } ? T : never;

This would clearify it a lot
export type Tag = User.repos[].pull_requests[].tags[];

Corner case
export class Hello {
  static world = 'world';
  world = 42;
}

export type ThisWillBeANumber = Hello extends { world: infer T } ? T : never;
export type ThisWillBeANumber = Hello.world;

export type ThisWillBeAString = (typeof Hello) extends { world: infer T } ? T : never;
export type ThisWillBeAString = (typeof Hello).world;

@lukaselmer It seems like you just want
export type Avatar = User["avatar"];

which works today

@lukaselmer It seems like you just want
export type Avatar = User["avatar"];

which works today

That's exactly what I was looking for. I was searching for it in the documentation, but didn't find it. Thank you!

Is this part of the handbook, or is there any official documentation on how this works? Im pretty familiar myself on how to use it, but when I try to direct people to documentation, all I can find is typeof guards, which is really completely different

So, I have noticed that this proposal bounced around from 2015 and one of the original goals was to somehow get the type of a single property of an interface.
interface {
 foo: bar;
 /* more types */
}

am I correct to assume that this is still not possible?

@MFry I think you're looking for this syntax: a['foo']

@MFry const example = (fooNeeded: a["foo"] ) => {}; should conver your case if I understand correctly.

Do we know if there is a solution for this yet?
I'm trying to get something like this:
declare function something<A, B>(): void;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<T extends ReturnType<typeof something>>(arg: T): { payload: unknown };

doThing(hello).payload === 123; // this should validate to a string aka type Payload

https://www.typescriptlang.org/play/index.html?ts=4.0.0-dev.20200512#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwGccBbEDACy1QHMAeAQQBp4AhAPgAoBKALngDccWYAG4AUGIwBPAA4IAClCkQcUYPAC8hDDCrVxYsHgIZ45EBBWbCJMpRq0A3gF9mi5auCcuB0JFgIKOjYePDAOAAq9nQR8CAAHhggqMAE8ABKZMgwqBGyILTScjiINqQUemycsNR8EbzwjvAySipqfGgA1qg4AO74zr6R0RzmljhcAHQtHmqaGloAjABMAMwi8AD0m-AVaQTkOMgQ6vxQEMJQSbs48FDaujR3nfdFCq2eYkA

Hi @maraisr I'm not 100% sure what you are trying to achieve. In your example something takes two types but does not use them, and hello is the return value of something which will always be void; So doThing never sees the type string at any point.
Maybe something like below is what you want?
declare function something<ReturnType>(): ReturnType;

type Payload = string;

const hello = () => something<Payload>();

declare function doThing<F extends () => any>(f: F): { payload: ReturnType<F> };

doThing(hello).payload === 'a string';

Ah yeah - so sorry about that. Thank you for the prompt response!! :100: @acutmore
The void was just to indicate that the returntype of that function is irrelevant. Those 2 types get forwarded onto other generic types, which ultimately get used in arguments.
something like:
declare function something<A, B>(a: MyComplexGeneric<A>, b: B[]): { somethingA: number, somethingB: number };

// Those 2 generics influence the return object so they do get used as such. And the 2 arguments are roughly that. Its an object and an array, more-or-less.

My doThing function doesn't really care what the first (A) generic is, but it does care what the second (B) on is.
See that something in my own usecase does a sideeffect which get read by the doThing.

If you feel this query is beyond the scope of this issue, ill continue my journey on StackOverflow!

@maraisr thanks for the extra info.
If you want to doThing to be able to get the original B type from something then it needs to be passed to hello in someway. TypeScript is only looking at hello and without some help it won't know that it is the return type of something.
This is one way that this can be done:
/** Create a type that can store some extra type information **/
interface SomethingResult<T> {
    __$$__: T;
    somethingA: number;
    somethingB: number;
}

declare function something<A, B>(): SomethingResult<B>;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<T extends any, Result extends SomethingResult<T>>(arg: Result): { payload: Result['__$$__'] };

doThing(hello).payload === 1123; // error becuase `payload` is of type string

interface User {
  avatar: string;
}

interface UserData {
  someAvatar: User['avatar'];
}

Why is this closed? This is could make so many things possible.

@RyanCavanaugh Why is this closed? Conditional Types don't solve this and many other use cases, and if this gets merged it would make so many things possible.
I'm working on a function that can turn any method call into a "point-free" version (example: [].map(() => n > 5) turns into map(() => n > 5)([]) and the only thing missing is that Conditional Types and infer can't detect generics, so in generic functions some types will come out as unknown.
If I could "call" the functions to get the type ( typeof myFunc(() => Either<string,number>)) it would be possible to have this functionality (that is currently impossible), and make many other things much easier to do (HKTs, etc...)
Is the complexity very high to be able to $Call a function (like in flow)? I feel like typescript already does it automatically.

@nythrox we don't feel that the syntactic confusion that this could lead to is outweighed by the cases where you need it to get to some type. The specific case of resolving a call expression is tracked elsewhere; the proposal in the OP of "allow any expression whatsoever" isn't something we think would be a good fit for the language.

@RyanCavanaugh oh okay, I understand. Thanks for the response, do you know what issues are tracking resolving a function call?

I have searched around a bit and have not found an issue for a function call utility type; the only reference to one I found was in #20352, which just linked back to this issue.

The specific case of resolving a call expression is tracked elsewhere

@RyanCavanaugh Mind linking to elsewhere? 🙂

@tjjfvi #37181 is more specically about resolving a function based on its inputs. Might be what you are looking for.

@acutmore That is somewhat along the lines of what I was looking for, though I was specifically talking about a flow-esque $Call utility, or other syntax to be able to implement such. The approach suggested there is strange, but thanks for the link.


Node process running after stopping app

Hello - I'm impressed by the great work in this project and I hope it will continue to evolve 👌. I'm playing around with a ASP.NET Core app, very similar to the demo app in this repo. When I stop the application after starting it from Visual Studio (Windows) there are still node process(es) running. I'm wondering if this is an known issue or if it is I who miss to make some call/dispose some resource in order to signal to Node that the web app has shut down.
Keep up the good work!

Sound a lot like this issue:
https://github.com/ElectronNET/Electron.NET/issues/68

You are right @AirLancer - they are probably related. Worth noting is that I do this before shutting down the ASP.NET application
ElectronNET.API.Electron.App.Quit();

I am still having this problem, Is there any solution?

I try to release a new version of the API as well - @GregorBiswanger told me, that there might be a fix included.

@pardahlman, @Jonatthu, @pardahlman - do you try out the newest version of API and CLI (0.0.9)?

Hi, @GregorBiswanger - not yet (I didn't know it included a potential fix for this!). Will upgrade later today and report back to you. Thanks!

0.0.9 is definitely more stable - thanks a bunch!

I have version 0.0.9 and have this issue

@flakron What OS do you use?

Sorry, should've left more information.
OS: Ubuntu 16.04,
Dotnet SDK version: 2.1.4
The backend doesn't seem to get that the windows is closed and keeps running in background.

After running & closing 5 times using v0.0.9 . Backend does contain threads but I do know from earlier versions and standalone backend that they stop correctly when told so. I use both OnClose/OnClosed to close the threads running within the back-end.
A simple hack that i can think of is just literally starting a kill command for the back-end process... but that still doesn't tell electron to close.

Fixed with the next Electron.NET update.

FWIW, I am still seeing this error.
I have a main menu where the user clicks File -> Exit (I only have 1 window)
        public void FileExit()
        {
            Console.WriteLine("File exit");
            var mainWindow = Electron.WindowManager.BrowserWindows.First();
            mainWindow.Close();
        }

And then I have an event listener which is attached the app first starts:
            Electron.App.WindowAllClosed += () =>
            {
                Console.WriteLine("All windows closed");
                Electron.IpcMain.RemoveAllListeners("EventListItem.Click");
                Electron.IpcMain.RemoveAllListeners("JsonEditor.Save");
                Electron.App.Quit();
            };

I am taking extra care to manually remove all event listeners to ensure this isn't the reason why it fails.
What happens is, the window closes, and the electron process goes away, but the API process remains in the task manager (Activity Monitor on Mac OSX).

After running & closing 5 times using v0.0.9 . Backend does contain threads but I do know from earlier versions and standalone backend that they stop correctly when told so. I use both OnClose/OnClosed to close the threads running within the back-end.
A simple hack that i can think of is just literally starting a kill command for the back-end process... but that still doesn't tell electron to close.
Edit: welp, i gave up and went directly to main.js file, and adding this fixed it:
app.on('window-all-closed', app.quit);

app.on('before-quit', () => {
    apiProcess.kill();
});

Can you share where that variable "app" came from in your site.js?


Fix some import/export dashbuilder doc mistakes/typos

Fixing some typos and wording problems as well as some factual mistakes.

Reviewed and merged on master & 6.2.x


Add edgeware and parallel heiko networks to production

Edgeware: ✔
Genesis

Properties

Parallel Heiko: ✔
Genesis

Properties


Changes to accommodate Joined Account Caching changes in ad-accounts

Also fixed issue where default scopes could be added multiple times.
Added Additional Extra query params related to Broker to MicrosoftTokenRequest
(Temporary hack) TBD : added to parse V1 idtoken upn in MicrosoftStsRequest to store the right value of displayable id in cache

Related ad-accounts PR : https://github.com/AzureAD/ad-accounts-for-android/pull/811

Thanks @shoatman