Repository navigation
Aliased Conditions with explicit type definition results in the "old" behavior #45469
Description
Bug Report
🔎 Search Terms
Aliased Conditions
🕗 Version & Regression Information
V4.4.0-beta / nightly
- I was unable to test this on prior versions because it is a new feature
⏯ Playground Link
Playground link with relevant code
💻 Code
type Shape =
| { kind: "circle", radius: number }
| { kind: "square", sideLength: number };
function area(shape: Shape): number {
const isCircle: boolean = shape.kind === "circle";
if (isCircle) {
// We know we have a circle here!
return Math.PI * shape.radius ** 2;
}
else {
// We know we're left with a square here!
return shape.sideLength ** 2;
}
}🙁 Actual behavior
Adding the explicit type to "isCircle" results in that the sample breaks
Property 'radius' does not exist on type 'Shape'.
Property 'radius' does not exist on type '{ kind: "square"; sideLength: number; }'.
Property 'sideLength' does not exist on type 'Shape'.
Property 'sideLength' does not exist on type '{ kind: "circle"; radius: number; }'.🙂 Expected behavior
Making the implicit type explicit, does not result in the behavior to change.
Using the sample provided by the TS 4.4 RC announcement, getting the implicit type of "isCircle" (by hovering over it) yields boolean
. By then explicitly defining the type (boolean), the Aliased Conditions seems to break/revert back to pre 4.4 behavior.
Activity
IllusionMH commentedon Aug 16, 2021
This is mentioned explicitly in PR that implements feature (#44730 after first code block):
WGroenestein commentedon Aug 17, 2021
Thanks for pointing out that indeed it seems to be by design according to the PR, and there is probably a good technical reason for why it is like that. However I would argue that from a functional (the consuming developer) perspective it is unexpected (and even inconsistent) behavior. I.e. a type which is determined by the compiler (i.e. the boolean presented to the developer) and a type annotation of that same type, is in my opinion expected to behave identical.
Imaging the following scenario:
Your team has the coding style to use explicit types for everything (e.g. for readability and code review purposes)
If I recall correctly at some point (and maybe even still today) it was even suggested to use explicit type annotations as a way to speed up the TS compilation process. And if that recollection is correct, it would mean that we now have conflicting rules for the usage of the TypeScript language.
What would be the best way forward? Should I close this bug and create a new issue with a feature request to enable this new awesome feature even when an explicit type annotation is present on the const?
DanielRosenwasser commentedon Aug 18, 2021
I can't necessarily comment on the original rationale; however, the current behavior allows users to "opt out" of using a condition for narrowing, and gives us room for some different sort of annotation in the future to signal "this is a boolean, and you should interpret the condition here".
DanielRosenwasser commentedon Aug 18, 2021
Perhaps something like
const isCircle: shape is Circle, like how type predicate signatures use.