You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Equivalence between tuple containing union type and union type of tuples #39357
I'm writing a union type of tuples, which are containing values which types are also union types.
The thing is, some of these values are mutually exclusive, so I can't write a single tuple ['a' | 'b', 'c' | 'd'], since I don't want the ['a', 'd'] pair to exist (for example).
I have to manually write the possible pairs, e.g. ['a', 'c'], ['b', 'c'] and ['b', 'd'], which is fine. However, when building a value for this type, by making some checks with conditional branching to make sure the first element is either 'a' or 'b', the type guard applied doesn't allow me to build a value of this type.
This seems to work well with objects (so it's a workaround I guess?), but I'd like to avoid the struggle of finding names - let's be honest, the hardest part of our job - for each property. Since objects and tuples are isomorphic, tuples should behave the same and not throw an error (cf. example).
I'm assuming such feature could have a significant impact regarding TSC performance: if our tuples contain union types with tens of possible values, then finding all the possible tuples for all these union types could be quite heavy.
Type '[number, "yes" | "no"] | [string, "maybe"]' is not assignable to type 'A'.
Type '[number, "yes" | "no"]' is not assignable to type 'A'.
Type '[number, "yes" | "no"]' is not assignable to type '[number, "yes"]'.
Type '"yes" | "no"' is not assignable to type '"yes"'.
Type '"no"' is not assignable to type '"yes"'.
I guess the same logic could be applied from #30779, which is only done for discriminated unions. Honestly, I'm not sure why we don't apply the same checks, since internally they're both just object types.
This seems to be failing because of logic added to propertiesRelatedTo specific to tuple types that ignores the excludedProperties set that is passed in when comparing to a discriminated union.
I would say that this is a bug as this is intended to work. Fixing this looks like it will require a simple one-line change in propertiesRelatedTo and some additional work in indexTypesRelatedTo to exclude the types of the excluded properties from comparison.
Activity
DanielRosenwasser commentedon Jul 1, 2020
I guess the same logic could be applied from #30779, which is only done for discriminated unions. Honestly, I'm not sure why we don't apply the same checks, since internally they're both just object types.
Any thoughts Ron Buckton (@rbuckton)?
rbuckton commentedon Jul 2, 2020
This seems to be failing because of logic added to
propertiesRelatedTospecific to tuple types that ignores theexcludedPropertiesset that is passed in when comparing to a discriminated union.rbuckton commentedon Jul 2, 2020
I would say that this is a bug as this is intended to work. Fixing this looks like it will require a simple one-line change in
propertiesRelatedToand some additional work inindexTypesRelatedToto exclude the types of the excluded properties from comparison.ruizb commentedon Jul 3, 2020
Hello there, I didn't realize it was actually a bug, I'm glad you found a fix so quickly! Thank you ❤️