Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional type does not narrow union type #29188

Open
lodo1995 opened this issue Dec 28, 2018 · 9 comments
Open

Conditional type does not narrow union type #29188

lodo1995 opened this issue Dec 28, 2018 · 9 comments
Labels
Bug A bug in TypeScript Domain: Conditional Types The issue relates to conditional types
Milestone

Comments

@lodo1995
Copy link

TypeScript Version: 3.2.2

Search Terms: conditional types, unions, narrowing

Code

    interface A<T> {
        value: T;
    }

    interface Specification {
        [key: string]: Array<any> | Specification;
    }

    type Mapping<S extends Specification> = {
        [key in keyof S]: S[key] extends Array<infer T> ? A<T> : Mapping<S[key]>
        // Error                                                         ^^^^^^
        // Type 'S[key]' does not satisfy the constraint 'Specification'.
        //   Type 'Specification[key]' is not assignable to type 'Specification'.
        //     Type 'any[] | Specification' is not assignable to type 'Specification'.
        //       Type 'any[]' is not assignable to type 'Specification'.
        //         Index signature is missing in type 'any[]'.
    };

Expected behavior:
No error. "Leafs" of the Specification tree, which have type Array<T> (for some T) should be mapped to A<T>, while non-leaf properties should be recursively mapped.

Actual behavior:
In the right-hand side of the conditional type, S[key] is not narrowed to Specification, even if the complete type of S[key] is Array<any> | Specification and the Array<any> case is catched in the left-hand side.

Playground Link: link

Related Issues: some similar issues related to conditional types, but I'm not sure whether this is a duplicate of any of them.

@fatcerberus
Copy link

Not 100% positive but I think this might have to do with the way conditional types interact with unions. The conditional type distributes over a union, i.e. it acts like a map operation. In other words the ternary is evaluated individually for each type in the union rather than treating it as a unit, and the final type is a union of that.

@lodo1995
Copy link
Author

Apparently it can be fixed by reversing the order and adding a second conditional to perform the inference on the right-hand side

type Mapping<S extends Specification> = {
    [key in keyof S]: S[key] extends Specification ? Mapping<S[key]>
                    : S[key] extends Array<infer T> ? A<T> : never
};

To be honest, this simple case doesn't even need a conditional, because you can get the element type of the array by doing A<S[key][0]>. But my real use case involves more complex types, including inference of function signatures, which can only be achieved with infer, as far as I know.

@jack-williams
Copy link
Collaborator

Conditional types do not produce substitution types for the false branch of the conditional (a.k.a do not narrow in the false branch).

There was an attempted fix here: #24821, however this was closed.

@lmcarreiro
Copy link

lmcarreiro commented Jan 3, 2019

Not sure if this is the same, but the compiler are behaving differently if I have an union of arrays vs array of union:

type A = { x: string };
type B = { x: string, y: number };

const arr1: (A | B)[] = [];
arr1.find(e => e.x === ""); // OK
arr1.map(e => e.x); // OK

const arr2: A[] | B[] = [];
arr2.find(e => e.x === ""); // OK
arr2.map(e => e.x); // Error: Cannot invoke an expression whose type lacks a call signature.

Shouldn't this arr2.map(e => e.x) work?

@jack-williams
Copy link
Collaborator

@lmcarreiro

This is a very different situation, and it is normal that a union of arrays behaves differently to an array of unions in some cases. There probably is some justification that the map should work, however this case involves synthesising a union of call signatures which is pretty complex. I would recommend reading over this PR by @weswigham, #29011, and any related issues. If you still have some queries I think it would be better to start a new issue, or reply to those, as this topic is very different to the initial question in this thread.

@weswigham
Copy link
Member

weswigham commented Jan 3, 2019

@jack-williams had identified the core of the issue. We use "substitution" types internally to track the constraints applied to a type within the true branch of a conditional, however we do no such tracking for the false branch. This means that you can't actually bisect a union type with a conditional right now, as @lodo1995 points out, you must chain two conditions and invert the check so your logic is in the true branch instead.

Part of the reason why we didn't move forward with #29011 (other than one of the relations I identified not holding up under scrutiny) is that tracking falsified constraints with substitution types kinda works... but when you perform the substitution, the information is lost, since we do not currently have a concept of a "negated" type (I mitigated this a little bit by remateriaizling the substitutions that tracked negative constraints late, but that's a bit of a hack). We cannot say that the given T extends string ? "ok" : T that the type of T in the false branch is a T & ~string , for example - we do not have the appropriate type constructors currently.

We regularly bring up how we really do probably need it for completeness, but the complexity "negated" types bring is... large? At least that's what we seem to think - it's not immediately obvious that a ~string is an alias for "any type except those which are or extend string", and therefore that a ~string & ~number is "any type except strings or numbers" (note how despite the use of &, the english you read as used the word "or").

So we're very aware of what needs to be done to make this work better... we're just having trouble convincing ourselves that it's "worth it".

@weswigham weswigham added Bug A bug in TypeScript Domain: Conditional Types The issue relates to conditional types labels Jan 3, 2019
@fatcerberus
Copy link

fatcerberus commented Jan 3, 2019

therefore that a ~string & ~number is "any type except strings or numbers" (note how despite the use of &, the english you read as used the word "or").

Personally I first read this as “all values which are not string AND not number”—only later switching to a negated “or” to simplify the clause mentally.

Maybe that’s just because I’ve been coding too long, though... 😛 I quickly recognize !(x || y) to be the same as (!x && !y) and vice versa.

@falsandtru
Copy link
Contributor

Duplicate of #21937.

@TotallyNotChase
Copy link

Alongside the narrowing mentioned here, Is it possible to add narrowing of union object types using in operator for conditional types?

E.g-

type Foo = string | { type: string };

type Bar<T extends string> = T;

type Qux<T extends Foo> = {
    [K in keyof T]: T[K] extends string ? Bar<T[K]> : T[K] extends { type: string } ? Bar<T[K]['type']> : never;
};

It'd be nicer if this was possible instead-

type Qux<T extends Foo> = {
    [K in keyof T]: 'type' in T[K] ? Bar<T[K]['type']> : Bar<T[K]>;
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: Conditional Types The issue relates to conditional types
Projects
None yet
Development

No branches or pull requests

8 participants