-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Closed
Labels
Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed
Description
Bug Report
π Search Terms
reduction, generic, union, intersection
π Version & Regression Information
This bug is also the 'Nightly' version. Versions prior to 4.6.2
give even more errors.
β― Playground Link
Playground link with relevant code
π» Code
type NumericLiteral = {
value: number;
type: "NumericLiteral";
};
type StringLiteral = {
value: string;
type: "StringLiteral";
};
type Identifier = {
name: string;
type: "Identifier";
};
type CallExpression = {
name: string;
arguments: DropbearNode[];
type: "CallExpression";
};
type DropbearNode =
| NumericLiteral
| StringLiteral
| Identifier
| CallExpression;
type Visitor = {
[K in DropbearNode["type"]]: (node: Extract<DropbearNode, { type: K }>) => void
};
function visitNode<K extends DropbearNode['type']>(node: Extract<DropbearNode, { type: K }>, v: Visitor) {
v[node.type](node) // error
}
π Actual behavior
typeof node.type
is inferred as (K & "NumericLiteral") | (K & "StringLiteral") | (K & "Identifier") | (K & "CallExpression")
that it is equal to K
itself considering that K extends "NumericLiteral" | "StringLiteral" | "Identifier" | "CallExpression"
.
Something goes really wrong when I try to use node.type
as an index, maybe because its type doesn't perform well if used as an index to access the Visitor
type.
π Expected behavior
typeof node.type
inferred as K
because it is simpler to interact with and doesn't give problems if used as an index.
Metadata
Metadata
Assignees
Labels
Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed