Mapped conditional types

[matt-hensley]

#12114 added mapped types, including recursive mapped types. But as pointed out by @ahejlsberg

Note, however, that such types aren't particularly useful without some form of conditional type that makes it possible to limit the recursion to selected kinds of types.

type primitive = string | number | boolean | undefined | null;
type DeepReadonly<T> = T extends primitive ? T : DeepReadonlyObject<T>;
type DeepReadonlyObject<T> = {
    readonly [P in keyof T]: DeepReadonly<T[P]>;
};

I couldn't find an existing issue with a feature request.

Conditional mapping would greatly improve the ergonomics of libraries like Immutable.js.

[Artazor]

Surely it should be implemented. However, need to find an appropriate syntax. There is possible clash with other proposal: #4890

[gentoo90]

Another possible use case is typeguarding Knockout.js mappings, which needs choosing between KnockoutObservable and KnockoutObservableArray.

In

interface Item {
    id: number;
    name: string;
    subitems: string[];
}

type KnockedOut<T> = T extends Array<U> ? KnockoutObservableArray<U> : KnockoutObservable<T>;

type KnockedOutObj<T> = {
    [P in keyof Item]: KnockedOut<Item[P]>;
}

type KoItem = KnockedOutObj<Item>

KoItem should be expanded to

type KoItem = {
    id: KnockoutObservable<number>;
    name: KnockoutObservable<string>;
    subitems: KnockoutObservableArray<string>;
}

[rotemdan]

Hi, I was just reading "GADTs for dummies" (which might be helpful for anyone interested in this issue) where GADT = "Generalized Algebraic Data Type". Although I'm not quite really there in getting a full understanding of the concept, it did occur to me that what is described here can alternatively be elegantly expressed through a form of "overloading", or more specifically, pattern matching, over type constructors:

type Primitive = string | number | boolean | undefined | null;

type DeepReadonly<T extends Primitive> = T;
type DeepReadonly<T> = { readonly [P in keyof T]: DeepReadonly<T[P]>; };

The idea is that this works just like regular pattern matching: given any type T the first pattern (T extends Primitive) is tested. If the type matches the constraint, then it is resolved, if not, it continues to the next pattern (<T>). Since there is no constraint on the second one, it acts similarly to otherwise or default and would accept anything that doesn't match the previous ones (Note the order of statements matters here: similarly to class method overloading it probably must be enforced that overloaded type declarations of similar identifiers strictly follow each other, to prevent accidental redefinition of types)

One thing that differs from the GHC extension syntax is that in the example I gave the type constructor overloads are anonymous. The reason they are named in Haskell, I believe, is to allow functions to directly switch or pattern match over different named constructors of the type. I believe this is not relevant here.

There's much more to this subject, I guess. It might takes some time for me to get an adequate understanding of GADTs and the implications of applying them here.

[rotemdan]

I'll try to give examples of other applications of such types:

Let's say I want to define a function that takes a value of any primitive type and returns the "zero" value corresponding to that value's type:

function zeroOf(val) {
	switch (typeof val) {
		case "number":
			return 0;
		case "string":
			return "";
		case "boolean":
			return false;
		default:
			throw new TypeError("The given value's type is not supported by zeroOf");
	}
}

How would you type this function? The best current solution offered by typescript is to use the union number | string | boolean as paramter type and and the union 0 | "" | false as return type:

(Edit: yes this can be improved to use overloaded method signature, but the actual signature would still look like this, I've explained the difference in another edit below)

function zeroOf(val: number | string | boolean): 0 | "" | false {
	// ...
}

However, the problem is that this doesn't allow "matching" a type argument to the correct member of the union.

But what if it was possible to define "overloaded" type aliases? you could very naturally define:

type ZeroOf<T extends number> = 0; 
type ZeroOf<T extends string> = "";
type ZeroOf<T extends boolean> = false;
type ZeroOf<T> = never;

function zeroOf(readonly val: number | string | boolean): ZeroOf<typeof val> {
	switch (typeof val) {
		case "number": // typeof val is narrowed to number. ZeroOf<number> resolves to 0!
			return 0;
		case "string": // typeof val is narrowed to string. ZeroOf<string> resolves to ""!
			return "";
		case "boolean": // typeof val is narrowed to boolean. ZeroOf<boolean> resolves to false!
			return false;
		default: // typeof val is narrowed to never
                         // ZeroOf<never> (or any other remaining type) also resolves to never!
			throw new TypeError("The given value's type is not supported by zeroOf");
	}
}

The combination of the overloaded type alias and literal types is so expressive here to the point where the signature almost "forces" a correct implementation of the function!

Here's another example, of an evaluator function. The function takes an expression object and returns an evaluation of it. The result could be either a number, a string, or a boolean. This would be the "normal" way to describe this:

function eval(expression: NumberExpr | StringExpr | AdditionExpr | EqualityExpr): number | string | boolean {
	if (isNumberExpr(expression) || isStringExpr(expression)) { // These could be user defined guards
		return expression.terms[0];
	} else if (isAdditionExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) + eval(expression.terms[1]);
	} else if (isEqualityExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) === eval(expression.terms[1]);
	}
}

What if it was possible to represent the exact expected mapping between the given expression type and the resulting evaluated return type, in a way where the correct return type could also be enforced within the body of the function?

(Edit: note this is somewhat comparable to an overloaded method signature, but more powerful: it allows the return type to be expressed clearly as a type, guarded on, checked and reused in the body of the function or outside of it. So it makes the mapping more "explicit" and encodes it as a well-defined type. Another difference is that this can also be used with anonymous functions.)

type EvalResultType<T extends NumberExpr> = number;
type EvalResultType<T extends StringExpr> = string;
type EvalResultType<T extends AdditionExpr> = number;
type EvalResultType<T extends EqualityExpr> = boolean;

function eval(readonly expression: NumberExpr | StringExpr | AdditionExpr | EqualityExpr): EvalResultType<typeof expression> {
	if (isNumberExpr(expression) || isStringExpr(expression)) { // These could be user defined guards
		return expression.terms[0];
	} else if (isAdditionExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) + eval(expression.terms[1]);
	} else if (isEqualityExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) === eval(expression.terms[1]);
	}
}

Edit: Seems like these examples are not "convincing" enough in the context of this language, though they are the ones that are classically used with GADTs. Perhaps I've tried hard to adapt them to the limitations of Typescript's generics and they turned out too "weak". I'll try to find better ones..

[dead-claudia]

@rotemdan

This might go well with #12885. In particular, most of your examples would be redundant:

function eval(readonly expression: NumberExpr): number;
function eval(readonly expression: StringExpr): string;
function eval(readonly expression: AdditionExpr): number;
function eval(readonly expression: EqualityExpr): boolean;
function eval(readonly expression: NumberExpr | StringExpr | AdditionExpr | EqualityExpr): string | number | boolean {
	if (isNumberExpr(expression) || isStringExpr(expression)) { // These could be user defined guards
		return expression.terms[0];
	} else if (isAdditionExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) + eval(expression.terms[1]);
	} else if (isEqualityExpr(expression)) { // This could be a user defined guard
		return eval(expression.terms[0]) === eval(expression.terms[1]);
	}
}

This proposal could partially solve my function-related issue, though:

interface Original {
    [key: string]: (...args: any[]) => any
}

interface Wrapped {
    [key: string]: (...args: any[]) => Promise<any>
}

// Partial fix - need a guard in the mapped `P` type here...
type Export<R extends Promise<any>, T extends (...args: any[]) => R> = T
type Export<R, T extends (...args: any[]) => R> = (...args: any[]) => Promise<R>

interface Mapped<T extends Original> {
    [P in keyof T]: Export<T[P]>
}

[rotemdan]

@isiahmeadows

I've read your proposal but wasn't 100% sure if that what was intended. I'm aware that a non-recursive use of this feature with functions could be seen as somewhat similar to method overloading (of the form Typescript supports). The main difference is that the return values (or possibly also argument values whose type is dependent on other argument types) would have a well-defined type that is natively expressible in the language, rather than just being implicitly narrowed as a compiler "feature".

Another advantage I haven't mentioned yet is that the return type could be expressed even if the argument itself is a union (or maybe a constrained generic type as well?) and could be propagated back to the caller chain:

function func1(const a: string): number;
function func1(const a: number): boolean;
function func1(const a: string | number): number | boolean {
  if (typeof a === "string") 
     return someString;  // Assume the expected return type is implicitly narrowed here to number.
  else if (typeof a === "number")
     return someBoolean; // Assume the expected return type is implicitly narrowed here to boolean.
}

function func2(const b: string | number) { // 
  const x = func1(b); // How would the type of x be represented?

  if (typeof b === "number") {
	  x; // Could x be narrowed to boolean here?
  }
}

In general I find the idea that a type could describe a detailed relationship between some set of inputs and outputs very powerful, and surprisingly natural. In its core, isn't that what programming is all about? If a type could, for example, capture more specific details about the mapping between say, different ranges, or sub-classes of inputs to the expected ranges/sub-classes of outputs, and those can be enforced by the compiler, it would mean mean that the compiler could effectively "prove" correctness of some aspects of the program.

Perhaps encoding these relationships is not actually the most difficult aspect, but "proving" them is. I've read a bit about languages like Agda and Idris that feature dependent types but haven't really got deeply into that. It would be interesting to at least find some very limited examples of how (enforceable) dependent types would look like in Typescript. I understand that it may be significantly more challenging to implement them over impure languages like Javascript though.

[dead-claudia]

It kind of helps that in languages like Idris and Agda, pattern matching is practically the only way to actually conditionally test things (if-then-else are language level for them). But yes, that declarative kind of mechanism is useful. It's why, in my limited experience, it's easier to read complex Idris types than equivalent Haskell or even TypeScript types. But I'm not quite as sold on how much that actually fits in with the rest of TypeScript stylistically. Programming language design is just as much an art form as it is a logical point of research and practicality.

…

On Tue, Dec 27, 2016, 11:42 Rotem Dan ***@***.***> wrote: @isiahmeadows <https://github.com/isiahmeadows> I've read your proposal but wasn't 100% sure if that what was intended. I'm aware that a non-recursive use of this feature with functions could be seen as somewhat similar to method overloading (of the form Typescript supports). The main difference is that the return values (or possibly also argument values whose type is dependent on other argument types) would have a well-defined type that is natively expressible in the language, rather than just being implicitly narrowed as a compiler "feature". Another advantage I haven't mentioned yet is that the return type could be expressed even if the argument itself is a union (or maybe a constrained generic type as well?) and could be propagated back to the caller chain: function func1(const a: string): number;function func1(const a: number): boolean;function func1(const a: string | number): number | boolean { if (typeof a === "string") return someString; // Assume the expected return type is implicitly narrowed here to number. else if (typeof a === "number") return someBoolean; // Assume the expected return type is implicitly narrowed here to boolean. } function func2(const b: string | number) { // const x = func1(b); // How would the type of x be represented? if (typeof b === "number") { x; // Could x be narrowed to boolean here? } } In general I find the idea that a type could describe a detailed relationship between some set of inputs and outputs very powerful, and surprisingly natural. In its core, isn't that what programming is all about? If a type could, for example, capture more specific details about the mapping between say, different ranges, or sub-classes of inputs to the expected ranges/sub-classes of outputs, and those can be enforced by the compiler, it would mean mean that the compiler could effectively "prove" correctness of some aspects of the program. Perhaps encoding these relationships is not actually the most difficult aspect, but "proving" them is. I've read a bit about languages like Agda and Idris that feature dependent types but haven't really got deeply into that. It would be interesting to at least find some very limited examples of how (enforceable) dependent types would look like in Typescript. I understand that it may be significantly more challenging to implement them over impure languages like Javascript though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12424 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AERrBHAzma1qmDqp36OT6UeRTNpgHRmUks5rMT_xgaJpZM4K4ssm> .

[rotemdan]

@isiahmeadows

Edit: Re-reading the responses, I think I might have been misunderstood: it was definitely not my intention to require the programmer to explicitly declare the complex return type - that would be tedious, but that the compiler could infer an "explicit" (in the sense of being well defined in the type system) type for the return value rather than just implicitly narrowing it as a localized "feature". I've also tried to come up with a more concise "abbreviated" form for the guarded type.

I've tried to re-read #12885 but I'm still not 100% sure if it describes the same issue as I mentioned here. It seems like it tries to address an aspect of overload inference that is somewhat related, but more like the "flip-side" of this issue:

// Unfortunately the parameter has to be 'const' or 'readonly' here for the 
// issue to be easily addressable. I don't believe these modifiers are currently 
// supported for function parameters but I'm using 'const' for illustration:
function func(const a: string): number;
function func(const a: number): boolean;
function func(const a: string | number): number | boolean {
	if (typeof a === "string") {
		return true; // <-- This should definitely be an error, but currently isn't.
	}
}

The weak return type checking in the body of overloaded function is a real world problem I've encountered many times and seems very worthy of attention. It might be possible to fix this through an implicit compiler inference "feature", but I felt that guarded polymorphic types could take it even a step further:

function func(const a: string): number;
function func(const a: number): boolean;
function func(const a: boolean): number[];
function func(const a: string | number | boolean) { // The return type is omitted by 
                                                    // the programmer. Instead, it it automatically
                                                    // generated by the compiler.
	if (typeof a === "string") {
		return true; // <-- Error here
	}
}

The generated signature could look something like:

// (The generated return type is concisely expressed using a 
// suggested abbreviated form for a guarded type)
function func(const a: string | number | boolean): 
	<typeof a extends string>: number, <typeof a extends number>: boolean, <typeof a extends boolean>: number[];

The abbreviated form (which is currently still in development), when written as a type alias, would look like:

type FuncReturnType = <T extends string>: number, <T extends number>: boolean, <T extends boolean>: number[];

As I've mentioned the type can be propagated back to the callers in an unresolved form if the argument type itself is a union, and it can even be partially resolved if that union is a strict sub-type of the parameter type:

// The argument type 'b' is a union, but narrower:
function callingFunc(const b: "hello" | boolean) {
	return func(b);
}

The signature of the calling function is generated based on a reduction of the existing guarded type to the more constrained union and substitution of the identifier used in the signature (a) with the target caller's parameter (b).

function callingFunc(const b: "hello" | boolean): 
	<typeof b extends "hello">: number, <typeof b extends boolean>: number[];

Perhaps this may seem, at first, like an "overly-engineered" solution, that takes it quite far but doesn't actually produce adequate amount of value in practice. It may be the case (though I'm not at all totally sure) if only simple types like string and number are involved, but what if the overloads described more fine-grained aspects of the parameters? like refinement types:

function operation1(const x: number<0..Infinity>): number<0..1>;
function operation1(const x: number<-Infinity..0>): number<-1..0>;
function operation1(const x: number) {
	// ...
}

Now what if multiple functions like these are composed?

function operation2(const x: number<0..10>): number<-10..0>;
function operation2(const x: number<-10..0>): number<0..10>;
function operation2(const x: number<-10..10>) {
	// ...
}

function operation3(const x: number<-10..10>): {
	return operation1(operation2(x));
}

To generate a signature for operation3 the compiler could "condense" this complex propagation of constrained unknowns into a simpler resulting signature:

function operation3(const x: number<-10..10>):
	<typeof x extends number<-10..0>>: number<0..1>, <typeof x extends number<0..10>>: number<-1..0>

I guess it wouldn't look as beautiful in Typescript as it would look with a more concise syntax like Haskell's, and the lack of pattern-matching, assurance of immutability of variables and purity of functions may reduce the usability of the feature, but I feel there's still a lot of potential here to be explored, especially since Typescript already performs disambiguation of unions using run-time guards, and has a variant of function overloading that is very atypical when compared with common statically typed languages.

Edits: I've corrected some errors in the text, so re-read if you only read the e-mail's version

[dead-claudia]

@rotemdan

To clarify #12885, it focuses on expanding the type inference for callers only, and it is very highly specific to overloads. I intentionally laid that focus, because I wanted to limit its scope. (It's much easier and more likely that a proposal will get somewhere when you keep it down to a single unit.)

So it is somewhat like a flip side, but the inverse of my proposal, using those same links to deduce the correct return type from the differing parameter type, would in fact be what you're looking for here.

It's an abstract enough concept it's hard to put it into precise terminology without delving into incomprehensible, highly mathematical jargon you'd be lucky to even hear Haskellers using.