Skip to content

Wrong inference from function return argument #13118

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

Closed
AlexGalays opened this issue Dec 22, 2016 · 3 comments · Fixed by #25937
Closed

Wrong inference from function return argument #13118

AlexGalays opened this issue Dec 22, 2016 · 3 comments · Fixed by #25937
Assignees
Labels
Bug A bug in TypeScript

Comments

@AlexGalays
Copy link

TypeScript Version: 2.2.0-dev.20161221

Code

type SomeParams<A> = { a: A, enter: (a: A) => void }

function canYouInferThis<A>(fn: () => SomeParams<A>): { aa: A } {
  return { aa: fn().a }
}

const result = canYouInferThis(() => ({ a: { bla: 33 }, enter: a => undefined }))
result.aa.bla // Doesn't compile

Expected behavior:
The A parameter should be inferred to be { bla: number }. It seems completely unambiguous to me.
Failing that, I would expect a warning about ambiguous inferred types.

Actual behavior:
The type of A is silently inferred to be {}

@DanielRosenwasser DanielRosenwasser added the Bug A bug in TypeScript label Dec 29, 2016
@DanielRosenwasser
Copy link
Member

Something that was a little easier for me to analyze:

interface Foo<A> {
    a: A;
    b: (x: A) => void;
}

declare function canYouInferThis<A>(fn: () => Foo<A>): A;

const result = canYouInferThis(() => ({
    a: { BLAH: 33 },
    b: x => { }
}))

result.BLAH;

@AlexGalays
Copy link
Author

Any news? Could this still make it for 2.4?

@mhegazy mhegazy added the Needs Investigation This issue needs a team member to investigate its status. label Jul 23, 2018
@mhegazy mhegazy added this to the TypeScript 3.1 milestone Jul 23, 2018
@weswigham
Copy link
Member

Right - so this is caused by how we currently perform contextual typing and inference. When we attempt to find the type of the first parameter of x => {} we get its contextual type - which is informed by the inference context for the surrounding signature. When we perform this instantiation, we have not created any inferences for A yet, so A is assigned its default inference, then assigned to the x parameter permanently. When we than actually dive into the object literal to make inferences, we see that the inference for A is already fixed to {}, and so ignore the "better" inference target.

I think the "skip context sensitive" pass we perform is generally supposed to alleviate this (so noncontextual inferences like the one here are performed first), but the issue arises because the pass effectively skipped - the entire top-level arrow () => ({..}) is marked as context sensitive, so we never dive into its return to get the potential context-insensitive inference from it.

Now, as it turns out, this is a fixable problem! We need only continue building a type in SkipContextSensitive checking mode, ignoring just the individually context-sensitive parameters (or simply all parameters - I don't really believe it matters since they should get picked up in the second pass provided they're not fixed in the first), rather than ignoring the entire signature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript
Projects
None yet
4 participants