-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Revert fix for intersections in template literals, fix differently #52836
Conversation
@typescript-bot test this |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at bb599af. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the perf test suite on this PR at bb599af. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at bb599af. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite (tsserver) on this PR at bb599af. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at bb599af. You can monitor the build here. |
Heya @jakebailey, I've started to run the extended test suite on this PR at bb599af. You can monitor the build here. |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at bb599af. You can monitor the build here. |
Heya @jakebailey, I've started to run the diff-based user code test suite (tsserver) on this PR at bb599af. You can monitor the build here. Update: The results are in! |
This comment was marked as outdated.
This comment was marked as outdated.
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
1 similar comment
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
Heya @jakebailey, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@jakebailey Here they are:
CompilerComparison Report - main..52836
System
Hosts
Scenarios
TSServerComparison Report - main..52836
System
Hosts
Scenarios
StartupComparison Report - main..52836
System
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. Details
|
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
This comment was marked as outdated.
This comment was marked as outdated.
@weswigham Do you have any commentary on this in general? I'm doubting my choice here; it does allow you to write template types that contain intersections, which, you can only use by creating more template literals (as in my Path example). However, I'm somewhat wondering if I should instead be treating these like unions, i.e. expand them out at the top where if you have say |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any commentary on this in general? I'm doubting my choice here; it does allow you to write template types that contain intersections, which, you can only use by creating more template literals (as in my Path example).
Hm, I think only being able to interact with branded holes with other branded types is kinda the point of branding your literal types. Simultaneously, today you can use a template literal to "unbrand" a branded type (I don't know how prevalent that is, and, obviously if you look at the prompting issue, it isn't desirable to some). I'm not crushed by replacing the "unbranding" behavior with respecting brands, though, since you can also "unbrand" a branded literal type with something like
type Unbrand<T, TBrand> = T extends infer Q & TBrand ? Q : never;
type Q = Unbrand<"a" & {ok: any}, {ok: any}>;
which is, IMO, better, since you have to specify what brands you're removing from the type.
However, I'm somewhat wondering if I should instead be treating these like unions, i.e. expand them out at the top where if you have say
a${A & B}b
, that it turns intoa${A}b
&a${B}b
.
No, I don't think that's right - intersected literals always become never
, so the only meaningful intersections are branded literals. So if you split the brand and the literal apart, you'd have an object alone inside a template hole, like making a/${"b" & {path:any}}/c
into a/b/c & a/${{path:any}}/c
, and that later type has basically no meaning (in fact, by current rules, it just makes the type into string
, which'll then evaporate entirely) - it's only useful when you consider it with what it's intersected with anyway.
Thanks for the feedback! I've made the changes. |
This breaks fragmented-store on DT. I'll get more details and file a bug. |
Hm, I could have sworn I ran dt. |
(But, that is why I decided to merge yesterday afternoon; so I could get this feedback sooner rather than later.) |
For #52345
This reverts #48044, which with nearly a year more experience no longer looks correct to my eyes (I regret merging it), and instead implements a different fix for the issue. This one instead avoids expanding out intersections, leaving them in place like the other non-string-y types.