-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Open
Labels
Help WantedYou can do thisYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone
Description
π Search Terms
inference generic types
π Version & Regression Information
- This changed between versions 5.6.3 and 5.7.2
- This changed in commit or PR Fixed an issue with contextual type for intersection properties (take 2) #52095
β― Playground Link
π» Code
class Variable<U, S extends string> {
constructor(public s: S) { }
u!: U;
}
function mkGeneric<U, S extends string>(s: S) {
return new Variable<U, S>(s)
}
type ExactArgNames<GenericType, Constraint> = GenericType & {
[K in keyof GenericType]: K extends keyof Constraint ? GenericType[K] : never
}
type AllowVariables<T> = Variable<T, any> | { [K in keyof T]: Variable<T[K], any> | T[K] }
type TestArgs = {
someArg: number
}
type TestArgsWithVars = AllowVariables<TestArgs>
function takesGeneric<V extends AllowVariables<TestArgs>>(a: ExactArgNames<V, TestArgs>): void {
}
let v = takesGeneric({someArg: mkGeneric("x")});
π Actual behavior
VVersion 5.7.2 of the compiler infers the variable type as Variable<uknown, "x"> and subsequently generates an error
π Expected behavior
VVersion 5.6.3 of the compiler infers the variable type correctly as Variable<number, "x">
Additional information about the issue
This is breaking most code that uses typed-graphql-builder typed-graphql-builder/typed-graphql-builder#85
Metadata
Metadata
Assignees
Labels
Help WantedYou can do thisYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some cases
Activity
silentNever
in intersections with other meaningful constituents #60876Andarist commentedon Dec 29, 2024
I opened a PR with an experiment that could address this: #60876 but, like I mentioned there, I'm not really that confident in the chosen solution.
Your use case is not quite what TS usually allows. Exact types are not a thing, and you are trying to emulate them here. I feel like this is usually "there might be dragons" territory ;p
In general, nested inferences are quite tricky on their own. Just take a look at this comment from the source code:
I hit this myself many times already. In some way, you just lucked out before on some of the contextual types being accidentally ignored and that's why the return type inference was able to flow into your inner inference when the outer one was still in progress.
That being said... this alternative to your types work: TS playground
spion commentedon Jan 1, 2025
Thanks. I did work around this by using a dummy conditional type but using Exclude for filtering keys seems cleaner.
[-]Possible regression in 5.7.2 compared to 5.6.3[/-][+]Possible regression of intersection types in 5.7.2 compared to 5.6.3[/+][-]Possible regression of intersection types in 5.7.2 compared to 5.6.3[/-][+]Possible regression of intersection type inference in 5.7.2 compared to 5.6.3[/+]