Skip to content
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

Strange type inference failure with literal types #19360

Closed
pelotom opened this issue Oct 19, 2017 · 3 comments
Closed

Strange type inference failure with literal types #19360

pelotom opened this issue Oct 19, 2017 · 3 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@pelotom
Copy link

pelotom commented Oct 19, 2017

TypeScript Version: 2.6.0-dev.201xxxxx

Code

type Foo = {
  field: 'a' | 'b' | 'c'
}

declare function foo<K extends string>(f: () => Record<K, Foo>): void;

foo(() => ({
  bar: { field: 'a' },
}))

Expected behavior:

This type checks.

Actual behavior:

Argument of type '() => { bar: { field: string; }; }' is not assignable to parameter of type '() => Record<"bar", Foo>'.
  Type '{ bar: { field: string; }; }' is not assignable to type 'Record<"bar", Foo>'.
    Types of property 'bar' are incompatible.
      Type '{ field: string; }' is not assignable to type 'Foo'.
        Types of property 'field' are incompatible.
          Type 'string' is not assignable to type '"a" | "b" | "c"'.

One can coax the compiler into figuring things out via an explicit type parameter

foo<'bar'>(() => ({
  bar: { field: 'a' },
}))

but it's not clear why this should be necessary. When foo is not generic, there's no problem:

type Foo = {
  field: 'a' | 'b' | 'c'
}

declare function foo(f: () => Record<string, Foo>): void;

foo(() => ({
  bar: { field: 'a' },
}))
@DanielRosenwasser
Copy link
Member

Also exhibits this:

declare function foo<K extends string>(f: () => Record<K, 'a'>): void;

foo(() => ({
   field: 'a',
}))

@mhegazy mhegazy added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Oct 24, 2017
@mhegazy
Copy link
Contributor

mhegazy commented Oct 24, 2017

This is a design limitation of our current approach to overload resolution. Context-sensitive functions (once whose parameters types, including this, may be affected by contextual type) will get their types the first time the function is visited. types in our current system do no evolve. so the first round of inference we still do not know what the return type of the function is, all we know is we have a generic type; that becomes the contextual type for the function return type. then we check the "a", and since that there is no contextual type that suggests a literal type, the string type is inferred.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 7, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

3 participants