First: this is awesome.

Next: I know there were questions around still being able to map arrays/tuples like objects if the need arises. Below are some constructs that seem to allow that (PromisifySomeKeysTuple and PromisifyIntersectionTuple); the question is: are they intended or unintended?

type PromisifyNormal<T> = { [K in keyof T]: Promise<T[K]> }
type PromisifyNormalObject = PromisifyNormal<{ a: string, b: number, c: boolean }>
// {a: Promise<string>, b: Promise<number>, c: Promise<boolean>}
type PromisifyNormalTuple = PromisifyNormal<[string, number, boolean]>;
// [Promise<string>, Promise<number>, Promise<boolean>]

type PromisifySomeKeys<T, KT extends keyof T = keyof T> = { [K in KT]: Promise<T[K]> }
type PromisifySomeKeysObject = PromisifySomeKeys<{ a: string, b: number, c: boolean }>
// {a: Promise<string>, b: Promise<number>, c: Promise<boolean>}
type PromisifySomeKeysTuple = PromisifySomeKeys<[string, number, boolean]>;
/* 
type PromisifySomeKeysTuple = {
  [x: number]: Promise<string | number | boolean>;
  "0": Promise<string>;
  "1": Promise<number>;
  "2": Promise<boolean>;
  length: Promise<3>;
  ...
}
*/

type PromisifyIntersectionTuple = PromisifyNormal<[string, number, boolean] & { randomProp: 1234 }>;
/* 
type PromisifyIntersectionTuple = {
  [x: number]: Promise<string | number | boolean>;
  "0": Promise<string>;
  "1": Promise<number>;
  "2": Promise<boolean>;
  length: Promise<3>;
  ...
  randomProp: Promise<1234>;
}
*/

This is really cool and I actually just asked if this was possible in 3.0 here.

I have had a play with this with the insiders build and it does exactly what I want:

class Maybe<T>{}

type MaybeTuple = [Maybe<string>, Maybe<number>, Maybe<boolean>];

type MaybeType<T> = T extends Maybe<infer MaybeType> ? MaybeType : never;
type MaybeTypes<T> = {[P in keyof T]: MaybeType<T[P]>};

type extractedTypes = MaybeTypes<MaybeTuple>;

my only comment would be that the type of extractedTypes when you mouse over it is:

type extractedTypes = {
    [x: number]: string | number | boolean;
    "0": string;
    "1": number;
    "2": boolean;
    length: {};
    includes: {};
    toString: {};
    toLocaleString: {};
    push: {};
    pop: {};
    concat: {};
    join: {};
    reverse: {};
    shift: {};
    slice: {};
    sort: {};
    splice: {};
    unshift: {};
    indexOf: {};
    lastIndexOf: {};
    every: {};
    some: {};
    forEach: {};
    map: {};
    filter: {};
    reduce: {};
    reduceRight: {};
    entries: {};
    keys: {};
    values: {};
    find: {};
    findIndex: {};
    fill: {};
    copyWithin: {};
}

whereas I would expect [string, number, boolean]

As far as I can tell this PR does not help in the case of the rxjs pipe function:

    pipe<A>(op1: OperatorFunction<T, A>): Observable<A>;
    pipe<A, B>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>): Observable<B>;
    pipe<A, B, C>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>, op3: OperatorFunction<B, C>): Observable<C>;
    pipe<A, B, C, D>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>, op3: OperatorFunction<B, C>, op4: OperatorFunction<C, D>): Observable<D>;
    pipe<A, B, C, D, E>(op1: OperatorFunction<T, A>, op2: OperatorFunction<A, B>, op3: OperatorFunction<B, C>, op4: OperatorFunction<C, D>, op5: OperatorFunction<D, E>): Observable<E>;

here the second type param of one element in the tuple is the first type param of the next element in the tuple.

Is this case currently supported?

Anders Hejlsberg (@ahejlsberg) I've been playing a bit with this and the compiler does seem not recognize the fact that a mapped array type will still be an array type for the purpose of rest parameters. Ex on 3.1.0-dev.20180813 i get this error:

type Promisify<T> = { [P in keyof T]: Promise<T[P]> };
// error:  A rest parameter must be of an array type.
async function  invokeWhenReady<T extends any[], R>(fn : (...a: T) => R, ...a: Promisify<T>) : Promise<R>{
    return null as any;
}

Is this a bug, or design limitation. Will it be addressed in the future ?

Titian Cernicova-Dragomir (@dragomirtitian) I think that's being tracked in #26163.

Joe Calzaretta (@jcalz) I don't think that issue fixes the specific case of rest types because they use a different assignment relation. I think the problem is that the rest type checking uses isRestParameterType, which in turn uses assignable relation, not the definitely assignable relation that was fixed.

Titian Cernicova-Dragomir (@dragomirtitian) Joe Calzaretta (@jcalz) Jack Williams (@jack-williams) The invokeWhenReady example above works with #26676. For example:

declare let ps: Promise<string>;
declare let px: Promise<number[]>;

const r = invokeWhenReady((s, x) => ({ s, x }), ps, px)  // Promise<{ s: string, x: number[] }>

For anyone who is struggling with prototype properties getting mapped as well (like in Roaders's #26063 (comment)), causing A rest parameter must be of an array type error, I found out that it can be solved by explicitly keeping prototype properties out of boxing:

type Boxified<T> = {
    [P in keyof T]: P extends keyof [] ? T[P] : Box<T[P]>
};

instead of

type Boxified<T> = {
    [P in keyof T]: Box<T[P]>
};

(It worked implicitly in v4.4.4, but seems to require explicit condition since 4.5.2, at least in a more complicated scenario)

Anders Hejlsberg (@ahejlsberg) it appears this only works on type aliases, rather than any homomorphic mapped type?

type Tuple = [1, 2];
type A<T> = { [K in keyof T]: string };

type WithAlias = A<Tuple> // [string, string]

type WithoutAlias = { [K in keyof Tuple]: string };
/*
  {
    [x: number]: string;
    0: string;
    1: string;
    length: string;
    ...
 */

It's always been surprising to me when the left and right hand sides of a type alias aren't interchangeable. At this point I wish an operator like := had been used for TS type aliases.

The higher-order behavior only applies to generics, so bare object type expressions are never homomorphic; only aliases are.

Sometimes I wish I could do a one-off tuple mapping inline instead of having to declare a type alias out of line. And very often, I wish I could distribute over a union type inline instead of using a distributive conditional type alias

See #27995