-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Fixed const reverse mapped types themselves to be treated as const #55794
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
Fixed const reverse mapped types themselves to be treated as const #55794
Conversation
// @strict: true | ||
// @noEmit: true | ||
|
||
declare function test1<const T>(obj: { |
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.
The first 3 test cases are testing objects and how readonly
, -readonly
, and lack of them impact the T
and the fresh object that is created by mapping over T
.
Those objects today would be constified for the most part but their properties wouldn't always be marked as readonly
when they should be. When readonly
modifier is used on the mapped type then that result (typeof obj
) has readonly
properties but the const
type parameter itself doesn't have them. This is consistent with #12589 . You might also want to recheck when/how readonly
is preserved/stripped on members of the reverse mapped type here
[K in keyof T]: T[K]; | ||
}): T; | ||
|
||
const result4 = test4(["1", 2]); |
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.
This is an especially important part of the fix. Currently T
is inferred as (2 | "1")[]
but it really should be readonly ["1", 2]
1dbd5f3
to
d6d1604
Compare
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.
There are also some other test cases that I'd like to add here but I'm not entirely sure what should be the expected results for them
const T, P extends keyof T
- this might iterate overP
which might be the subset ofkeyof T
. Should we still assign constness toT
in such a case? See the playground TS playground. Note that it's not really possible to gatherP
across from different mapped types and somehow different mapped type to build up a "combined" reverse mapped type: TS playgroundK in keyof T | "extra"
- what should happen with a non-homomorphic case like this? TS playground
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.
- Probably? I'm not a huge fan of overuse of
const
type variables, but if they're in-use, there a strong signal that const-ness is desired somewhere related to that type parameter. The workflow is usually "does this do what I want? No? Add aconst
.", so theconst
normally only gets added by people if it's meant to be meaningful to inference. - Eh, I'd leave that as whatever it falls out as from being not homomorphic. It'll get unified if and when we ever adjust the logic to consider something like that as homomorphic-enough to get the homomorphic type variable treatment.
@typescript-bot test this |
Heya @weswigham, I've started to run the diff-based top-repos suite on this PR at d6d1604. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at d6d1604. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the regular perf test suite on this PR at d6d1604. You can monitor the build here. Update: The results are in! |
@weswigham Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@weswigham Here are the results of running the top-repos suite comparing Everything looks good! |
Hey @weswigham, the results of running the DT tests are ready. |
No description provided.