Activity

1. MartinJohns commented on Oct 26, 2022

   

   Martin Johns (MartinJohns)

   on Oct 26, 2022

   Last edited by MartinJohns

   Contributor

   More actions

   In one case you have an object that can either store a or b, in the other case you either have an object that can only store a, or an object that can only store b. The types are not equivalent.

   Although the assignment of outer to inner is already unsound.
2. sluukkonen commented on Oct 26, 2022

   

   Sakumatti Luukkonen (sluukkonen)

   on Oct 26, 2022

   Author

   More actions

   Perhaps this is a more motivating example. I'm basically trying to use a custom result type that tracks possible errors, a bit like Haskell's Either or Rust's Result. However, when trying to use it in practice, the ergonomics isn't great, since TypeScript requires me to add quite a bit of type annotations to make the code compile.

   interface Success<T> {
       ok: true
       value: T
   }
   
   interface Failure<E> {
       ok: false
       error: E
   }
   
   type Result<T, E> = Success<T> | Failure<E>
   
   const success = <T>(value: T): Success<T> => ({ok: true, value})
   const failure = <E>(error: E): Failure<E> => ({ok: false, error})
   
   declare function test<T, E>(fn: (value: unknown) => Result<T, E>): Result<T, E>
   
   // This works, for whatever reason.
   test((val) => {
       if (typeof val !== "string") return failure("not a string" as const)
       if (val.length === 0) return failure("empty string" as const)
       return success(val)
   })
   
   // This doesn't work. Why is that?
   test((val) => {
       if (typeof val !== "string") return failure({code: "not a string"} as const)
       if (val.length === 0) return failure({code: "empty string"} as const)
       return success(val)
   })
   
   // With an explicit type annotation, everything is ok.
   test((val): Result<string, {code: "not a string" | "empty string"}> => {
       if (typeof val !== "string") return failure({code: "not a string"} as const)
       if (val.length === 0) return failure({code: "empty string"} as const)
       return success(val)
   })

   👍React with 👍1Reacted by Artyom Desyatnikov
3. RyanCavanaugh commented on Oct 27, 2022

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Oct 27, 2022

   Member

   More actions

   A few things to discuss.

   First, for types with a single value of their type parameter, indeed X<T | U> === X<T> | X<U>. TS is incomplete on this measure because it, in general, will instead rely on comparison using variance measurement when comparing two instantiations of the same generic type rather than structural comparison. However, using variance is absolutely critical for performance reasons. Figuring out what correctly constitutes a "single value" is also pretty tricky once you move beyond simple properties.

   Second, in general, generic inference won't collect two disparate candidates and then infer to a union of them. This makes generics for the purposes of input validation largely useless, e.g. a call to something like find<T>(someNumberArray, someString) should not make a (sound!) inference of T = string | number, since reuse of a type parameter is intended to indicate at least some linkage of types. Callers intending that behavior can and should write find<string | number>(... in that case.

   The middle test call is, from inference's perspective, an equivalent situation. There are two candidates to collect for E with no common type amongst them, but TS isn't willing to construct a union between them (nor would that union even work, given the lack of the single-use equivalence reduction rule noted above).

   👍React with 👍1Reacted by Ricardo Fernández Serrata

   👀React with 👀1Reacted by Ricardo Fernández Serrata
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   Not a DefectThis behavior is one of several equally-correct optionsThis behavior is one of several equally-correct options

   on Oct 27, 2022
5. github-actions commented on Jun 8, 2023

   

   github-actionsBot

   on Jun 8, 2023

   More actions

   This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
6. github-actions

   closed this as not plannedon Jun 8, 2023
7. microsoft

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