[Feature Request] Type guard on conditional types #23493

Activity

1. jack-williams commented on Apr 18, 2018

   

   Jack Williams (jack-williams)

   on Apr 18, 2018

   Last edited by jack-williams

   Collaborator

   More actions

   I'm not sure narrowing would be sound:

   let x: Test<string, boolean> = { multiple: true, value: "hello" };
   typeGuard<string, boolean>(x);
   /*
       Passes type-checker.
       input.multiple === true does not imply input.values is present.
   */

   Why not use a union type with a discriminant property? (requires --strictNullChecks).

   type Test<V> = { multiple: true; values: V[] } | { multiple?: false; value: V };
   
   function typeGuard<V>(input: Test<V>) {
       if (input.multiple) {
           return input.values;
       } else {
           return input.value;
       }
   }
2. Ryan Cavanaugh (RyanCavanaugh)

   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 Apr 18, 2018
3. Kingwl commented on Apr 23, 2018

   

   Wenlu Wang (Kingwl)

   on Apr 23, 2018

   Contributor

   More actions

   have this issue any plan?🤫
4. Cryrivers commented on Apr 23, 2018

   

   Zhongliang Wang (Cryrivers)

   on Apr 23, 2018

   Last edited by Cryrivers

   Author

   More actions

   Wenlu Wang (@Kingwl) probably no plans yet as marked as Working as intended. For most cases you can use discriminant properties to solve the problem, which Jack Williams (@jack-williams) posted. My case is more complicated than his (or mine, as I posted the simplified case to demo my idea) and it is unlikely to be done with discriminant properties. I'll post a demo if I have time.

   Thanks.
5. Kingwl commented on Apr 25, 2018

   

   Wenlu Wang (Kingwl)

   on Apr 25, 2018

   Last edited by Kingwl

   Contributor

   More actions

   Zhongliang Wang (@Cryrivers)
   thanks for your suggestion
   I mean i'd like to try this if have not any plan or owner to fix this
6. kpdonn commented on Apr 25, 2018

   

   Kevin Donnelly (kpdonn)

   on Apr 25, 2018

   Contributor

   More actions

   Wenlu Wang (@Kingwl)

   I think the thing is that it can't be safely fixed due to Jack Williams (@jack-williams) example. The problem is that the types for Test can look like any of the following:

   type Test<V, M extends boolean> = { multiple?: M } & (
       M extends true ? { values: V[] } : { value: V }
   )
   
   type TestTrue = Test<string, true> // { multiple?: true; } & { values: string[]; }
   type TestFalse = Test<string, false> // { multiple?: false; } & { value: string; }
   type TestBoolean = Test<string, boolean>
   // ({ multiple?: boolean; } & { values: string[]; }) | ({ multiple?: boolean; } & { value: string; })

   It's the third case that makes

   let x: Test<string, boolean> = { multiple: true, value: "hello" };

   a valid assignment and would make the proposed narrowing unsound.

   Although as a side note you can force Test<string, boolean> to be a compile error by doing:

   type XorBoolean<B extends boolean> = boolean extends B ? never : boolean
   type Test2<V, M extends XorBoolean<M>> = { multiple?: M } & (
       M extends true ? { values: V[] } : { value: V }
   )
   type Test2True = Test2<string, true> // { multiple?: true; } & { values: string[]; }
   type Test2False = Test2<string, false> // { multiple?: false; } & { value: string; }
   type Test2Boolean = Test2<string, boolean> // error: type boolean does not satisfy constraint never

   Still doesn't narrow in the original example however since type constraints like that aren't taken into account.

   Playground link of examples
7. typescript-bot commented on May 11, 2018

   

   TypeScript Bot (typescript-bot)

   on May 11, 2018

   Contributor

   More actions

   Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
8. TypeScript Bot (typescript-bot)

   closed this as completedon May 11, 2018
9. microsoft

   locked and limited conversation to collaborators on Jul 31, 2018