-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible regression in 3.4 with distributive conditional types #30569
Comments
can you explain why you do this:
instead of just
|
@Aleksey-Bykov Because I want a union of all possible keys in a union. For example Using the distributive behavior of conditional types, |
control over distributivness need its own syntax, otherwise it looks like black magic, sorry for derailing |
The condition Changing the conditional to use T extends unknown ? Exclude<UnionKeys<TAll>, keyof T> : never I'm not sure what merit there is in creating a substitution type with |
@jack-williams After posting I found some of the existing GH issues. I still find this is a pretty big breaking change. Back in 2.8 when conditional types were introduced, I know Also I would kindly ask someone on the team (@RyanCavanaugh) to document this somewhere. It is not mentioned in the RC announcement or in the Breaking changes section. I'm not sure if it would have helped me but it would be useful to have some official docs to point to if it comes up in other contexts. |
@jack-williams tracked it down almost exactly - in
There is not, IMO - they only ever delete important information. My fix will be modifying the internal constructor such that substitutions which substitute |
TypeScript Version: 3.4.0-dev.201xxxxx
Search Terms:
Code
Expected behavior:
R
should be"a" | "b"
(as it previously was in 3.3)Actual behavior:
R
isnever
in 3.4Playground Link: link
Related Issues: Probably cause by #29437, #30489
The code above is a simplification of the
StrictUnion
type I posted on SO, and this issue was reported there as a comment. The type was also included by another SO user in SimplyTypedWorkaround
For the
StrictUnion
type a simple workaround is to pass in union keys toStrictUnionHelper
. This will achieve the same result as in 3.4:If breaking change is intended, I would like some guidance on whether the workaround version is likely to remain stable in the next releases or if there is a fundamental issue with the idea behind the type.
The text was updated successfully, but these errors were encountered: