Activity

1. andrewbranch commented on Sep 2, 2021

   

   Andrew Branch (andrewbranch)

   on Sep 2, 2021

   Member

   More actions

   I think my eyes are just tripping over all the square brackets, but can you explain why you expect your expected behavior? Here’s what I see:

   • data[0][0] is K[] | V. No argument here.
   • Asking if that type is an array narrows it to K[]. This is unsound because it ignores the possibility that V itself is instantiated with an array type. Every other type that follows from this flawed assumption is technically wrong, the first of which is result as K in both functions. It should arguably be unknown, but that would be a bummer.
   • In working, I think you just defeat the narrowing logic by grabbing a reference to a higher-up property than the one that was narrowed. (This will possibly be “fixed” by Type guard by deep property #38839.)

   So, I think I agree with your conclusion (on technical grounds, but this is a known/desired unsoundness that we really don't want to get rid of without negated types), but I wonder if you used the same logic to get there, because the easier way to demonstrate my conclusion is just by saying that result should be unknown in both functions.
2. benlesh commented on Sep 2, 2021

   

   Ben Lesh (benlesh)

   on Sep 2, 2021

   Last edited by benlesh

   Author

   More actions

   This is a minimal reproduction of a situation a co-worker hit. Basically this is some deserialized nonsense from a server and he wanted to add some type safety around it. (I actually pointed out to him that one type is a superset of the other) Either way, it seems like a strange technical error. I just wanted to bring it to your attention. I'm not sure how else this could manifest or even if it does. 🤷‍♂️

   Specifically, I don't necessarily agree with the logic above, It's just that I saw the strange type result and I thought I would report it.
3. andrewbranch commented on Sep 2, 2021

   

   Andrew Branch (andrewbranch)

   on Sep 2, 2021

   Member

   More actions

   Well, ignore my explanation for the moment. Can you explain why you expected your expected behavior? The flaw I pointed out in my explanation is fairly subtle, and if I take off my pedantic hat, the actual behavior looks correct to me.
4. benlesh commented on Sep 3, 2021

   

   Ben Lesh (benlesh)

   on Sep 3, 2021

   Author

   More actions

   Honestly, the structure/logic of the code doesn't really matter to me, that's just copy pasta from the code I was helping look at. It's the second part, and how it's effected by the Array.isArray check.

   1. The type system can't guarantee that the V generic won't be an array. So the Array.isArray check can't possibly narrow anything. If V is a known type or extends some non-Array, then it can absolutely narrow it down, but there's no constraints in this code.
   2. Since data[0] is V[] | [K[], V[]], Then I'd think data[0][0] should always be V | K[]. Why would pulling data[0] into it's own variable make a difference?

   Here's a more specific example

   type KeysAndValues<K, V> = [[K[], V[]]];
   type JustValues<V> = [V[]];
   
   function borked<K, V>(data: KeysAndValues<K, V> | JustValues<V>): void {
       if (!Array.isArray(data[0][0])) {
           // This shouldn't matter, because you can't guarantee
           // that V is or isn't an Array.
           const a = data[0][0]; // INCORRECT: V
       }
       const b = data[0][0]; // CORRECT: V | K[]
   }

   Put another way: This is only a problem generics, because generics could be arrays -- or anything else -- in this case. If you add hard types, it doesn't have any issues, as the Array.isArray actually does make a bit of difference, as you can see in this playground

   type KeysAndValues<K, V> = [[K[], V[]]];
   type JustValues<V> = [V[]];
   
   function unborked(data: KeysAndValues<string, number> | JustValues<number>): void {
       if (Array.isArray(data[0][0])) {
           const result = data[0][0][1];
       } else {
           const result1 = data[0][1];
           const result2 = data[0][0]; // CORRECT: number
       }
   }
5. benlesh commented on Sep 3, 2021

   

   Ben Lesh (benlesh)

   on Sep 3, 2021

   Author

   More actions

   Here's another way to put it that shows how this is broken

   
6. andrewbranch commented on Sep 3, 2021

   

   Andrew Branch (andrewbranch)

   on Sep 3, 2021

   Member

   More actions

   Ok right, we’re on the same page then. Because we don’t have negated types, there are all kinds of places we make unsound assumptions about what a type parameter is not. Consider an analogous example:

   async function f<T extends { id: string }>(x: T | Promise<string>) {
     const awaited = await x; // T | string;
   }

   Here we assume that await cannot have an effect on the type T because T does not look like a Promise, so the await should just unwrap the Promise<string> or no-op on the T. But T is absolutely allowed to be instantiated with something Promise-like, as long as that Promise-like type also has an id: string property. Because T might be Promise-like, the only sound type for awaited is unknown, because if T happens to be Promise-like, we have no idea what type it will resolve to. The only way to square this circle is using a negated type as a constraint for T as a way to say “has an id and does not have a callable then.” But we have no way to express that, so we have to choose between being correct and being useful, and we choose utility.

   The array case is the same. It’s often useful, though incorrect, to assume that V is not an array. If you know that it really might be in practice, you need to come up with some way to defeat the narrowing. One way might be to constrain it to something like string | number | boolean | object | unknown[] to make the compiler deal with the fact that it really might be array-like.

   Why would pulling data[0] into it's own variable make a difference?

   Because the narrowing engine is just not that smart. You narrowed on data[0][0]—we don’t recognize that this could imply anything about data[0]. You will only see refinements on data[0][0] and its sub-properties. Like I said, this will probably be fixed by #38839, making our behavior here consistently unsound. But you’ll always be able to find ways like this to defeat control flow narrowing.
7. Andrew Branch (andrewbranch)

   added

   Working as IntendedThe behavior described is the intended behavior; this is not a bugThe behavior described is the intended behavior; this is not a bug

   on Sep 3, 2021
8. typescript-bot commented on Sep 7, 2021

   

   TypeScript Bot (typescript-bot)

   on Sep 7, 2021

   Contributor

   More actions

   This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
9. TypeScript Bot (typescript-bot)

   closed this as completedon Sep 7, 2021
10. timbodeit commented on Nov 5, 2021

    

    Tim Bodeit (timbodeit)

    on Nov 5, 2021

    More actions

    It seems to me that the type of awaited could be expressed more specifically than unknown as string | (T extends Promise<infer U> ? U : T)

    because if T happens to be Promise-like, we have no idea what type it will resolve to.

    While we don't know what type it will resolve to, that doesn't mean we're completely unable to reason about it on a generic level and convey that information back to the calling context.

    Playground example

    I'm trying to think of cases where an unsound lowering to string | T would be more useful than inferring string | (T extends Promise<infer U> ? U : T).
    Thinking about it this way both #45686 / #46534 as well as the generic await example remind me of the way unions with undefined or null are treated. We have a strictNullChecks flag to let the user decide whether he wants the "utility" of just ignoring undefined and null or the "correctness" of always having full handling of possible undefined value cases enforced.

    Should this issue perhaps be resolved in a similar way?

    • Intended behavior in non strict mode: Make the unsound assumption, that a generic parameter T does not conform against a common parent type shared with other more explicitly declared types in the union.
    • Strict behavior guarded behind a new strict checking flag: Account for the fact that generic parameters can also satisfy the same typeguards applying to other union members and enforce explicit handling of the case that they do.

    ---

    On a more general note:

    so we have to choose between being correct and being useful, and we choose utility

    Andrew Branch (@andrewbranch) Does the TypeScript project have some more general policy on when to choose correctness vs utility documented somewhere, that I could read up on?

    When running the TypeScript compiler with the strict flag being set, I would expect the compiler to not make any (intentional) unsound assumptions about the types in my code. Making unsound assumptions for increased usability would be a feature, I'd expect to be limited to non fully strict operating modes. Is that not the case / goal?
11. microsoft

    locked as resolved and limited conversation to collaborators on Oct 21, 2025