Discriminant property type guard not applied with bracket notation

TypeScript Version: 2.0.0

Code

interface Square {
    kind: "square";
    size: number;
}

interface Rectangle {
    kind: "rectangle";
    width: number;
    height: number;
}

interface Circle {
    kind: "circle";
    radius: number;
}

type Shape = Square | Rectangle | Circle;

function area(s: Shape) {
    // In the following switch statement, the type of s is narrowed in each case clause
    // according to the value of the discriminant property, thus allowing the other properties
    // of that variant to be accessed without a type assertion.
    switch (s['kind']) {
        case "square": return s.size * s.size;
        case "rectangle": return s.width * s.height;
        case "circle": return Math.PI * s.radius * s.radius;
    }
}

Expected behavior:

The code compiles without errors.

Actual behavior:

sample.ts(24,33): error TS2339: Property 'size' does not exist on type 'Square | Rectangle | Circle'.
sample.ts(24,42): error TS2339: Property 'size' does not exist on type 'Square | Rectangle | Circle'.
sample.ts(25,36): error TS2339: Property 'width' does not exist on type 'Square | Rectangle | Circle'.
sample.ts(25,46): error TS2339: Property 'height' does not exist on type 'Square | Rectangle | Circle'.
sample.ts(26,43): error TS2339: Property 'radius' does not exist on type 'Square | Rectangle | Circle'.
sample.ts(26,54): error TS2339: Property 'radius' does not exist on type 'Square | Rectangle | Circle'.

Why this is bad:

I am trying to work with Dropbox's new 2.0 SDK, which heavily uses tagged union types (especially for API errors). The discriminant property is named .tag, so it can only be accessed via bracket notation. I generated TypeScript typings for their new JavaScript SDK, and discovered this bug the hard way. :(

👍 Bracketed property access should work the same as dotted property access for the purposes of type guards when the indexed name matches a known property

Fix is up at #10565

Update from the PR at #10530: narrowing on element access, even just for strings and not numbers, adds 6.5% time to the checker, so this is not likely to go into 2.1 unless we come up with a way to reduce its cost.

Nathan Shively-Sanders (@sandersn)

Nathan Shively-Sanders (@sandersn) thanks for the update. That's unfortunate, but understandable. :(

the original example from this issue seems to have been fixed at some point between typescript 2.0 and 3.3.3333

playground

the other examples in this thread seem to be slightly different, perhaps the original issue should be updated with a more up to date example or closed in favor of a different issue (such as #51368)?

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh), as DetachHead mentioned - the original example from this issue has been fixed a long time ago. A lot of other examples posted here are also working just fine today. I would propose closing this issue in favor of other ones that are reporting more specific things.

If we're not going to close this, could someone edit the title and description to reflect the current purpose of the issue? Right now it's just generating noise in every issue closed as a duplicate of this one.

As others have mentioned, this issue title/description isn't particularly clear, but from the issues marked as duplicate I'm guessing this issue is the same root cause as the following?

declare const apple: { [key: string]: boolean | undefined }
const banana: Record<string, boolean> = apple // error
// Type '{ [key: string]: boolean | undefined; }' is not assignable to type 'Record<string, boolean>'.
//   'string' index signatures are incompatible.
//     Type 'boolean | undefined' is not assignable to type 'boolean'.
//       Type 'undefined' is not assignable to type 'boolean'.(2322)

Micah Zoltu (@MicahZoltu)

Micah Zoltu (@MicahZoltu) I don't think that's the same issue, and I don't think the example that you shared would be considered an issue in TypeScript. Although a Record<string, boolean> and a Record<string, boolean | undefined> act very similarly, they differ in whether TS allows undefined to be explicitly assigned to properties, and they're consistently different in how TS does type checks of property values. See this playground link.

Closing since the examples cited here work as expected

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) in that case can any of the issues that were closed as a duplicate of this one be re-opened? Eg. #51368

DetachHead

DetachHead let's just get a fresh issue with a clear statement of the problem for clarity

Well, I opened #56389... not sure if it covers all the loose ends, though.

To anybody following this issue and confused like me, also the more complicated topic of variable index access type guards was fixed this June by ahejlsberg himself with #57847 in TS 5.5 :)

the issue i raised (#51368) which was closed as a duplicate of this one still doesn't work:

interface Data {
    a?: number
}

declare const data: Data

declare let key: 'a'

if (data.a !== undefined) {
    key // "a"
    const a = data[key] // number | undefined
    const b = data['a'] // number
}

playground

the difference being that key is a let instead of a const. in #57847 it mentions that it should work on both const and let:

With this PR we perform control flow analysis for element access expressions obj[key] where key is a const variable, or a let variable or parameter that is never targeted in an assignment.

or is there something i'm missing?

You're missing that the let is in the global scope and so other files might affect it, see #58972 (comment)

i see, thanks. it also seems like attempting it to narrow it with data.a then accessing it with data[key] also doesn't work, so i had to change that too:

+ export {}
+   
  interface Data {
      a?: number
  }
  
  declare const data: Data
  
  declare let key: 'a'
  
- if (data.a !== undefined) {
+ if (data[key] !== undefined) {
      key // "a"
      const a = data[key] // number | undefined
      const b = data['a'] // number
  }

Navigation Menu

Repository navigation

Discriminant property type guard not applied with bracket notation #10530

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Discriminant property type guard not applied with bracket notation #10530

Description

Activity

RyanCavanaugh commented on Aug 25, 2016

sandersn commented on Aug 26, 2016

sandersn commented on Oct 13, 2016

jvilk commented on Oct 17, 2016

32 remaining items

DetachHead commented on Nov 1, 2022

Andarist commented on Jan 8, 2023

jcalz commented on Apr 1, 2023

MicahZoltu commented on Sep 12, 2023

joshkel commented on Sep 12, 2023

RyanCavanaugh commented on Nov 13, 2023

DetachHead commented on Nov 13, 2023

RyanCavanaugh commented on Nov 13, 2023

jcalz commented on Nov 14, 2023

phil294 commented on Oct 15, 2024

DetachHead commented on Oct 16, 2024

jcalz commented on Oct 16, 2024

DetachHead commented on Oct 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions