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

Type inference lacking on index signature types #5089

Closed
alexeagle opened this issue Oct 3, 2015 · 4 comments
Closed

Type inference lacking on index signature types #5089

alexeagle opened this issue Oct 3, 2015 · 4 comments

Comments

@alexeagle
Copy link
Contributor

The compiler gives an error on the last line:

function s(p: {[k:string]:string}) {
    console.log(p);
}

let t: {[k:string]:string} = {thing: 'otherthing'};
s(t);

let t2 = {thing: 'otherthing'}; 
s(t2);

Index signature is missing in type '{thing: 'otherthing'}'

Which is very sad since I'm refactoring all of angular to use string index signatures instead of our hacky StringMap (angular/angular#4483)

@danquirk
Copy link
Member

danquirk commented Oct 3, 2015

The reason for this rule was because we could not guarantee that t2 did not get additional properties after initialization that would make it invalid for use with s. For example:

let t2 = {thing: 'otherthing'};
t2 = {thing: 'otherotherthing', foo: 1 }
s(t2); // s is going to assume t2.foo is a string though

The rule is that object literals that are contextually typed by a type with an indexer signature then get the index signature pushed into the literals type (this is what happens to t). However, now the code I posted above is an error under the new object literal strictness checks. But the strictness rules only extend so far:

let t2 = {thing: 'otherthing'};
let t3 = {thing: 'otherotherthing', foo: 1 }
t2 = t3;
s(t2); // error

@alexeagle
Copy link
Contributor Author

Okay, thanks for explaining. I'm almost done adding explicit types.

What about this case, where I get an error, it seems like the type narrowing within the type guard should work?

function s(p: {[k:string]:string}) {
    console.log(p);
}

class Foo {}
function l(q: Foo | {[key: string]: any}) {
  if (q instanceof Foo) {
      console.log(q);
  } else {
      s(q);  // <--- still a union, thinks it might be a Foo
  }
}

@RyanCavanaugh
Copy link
Member

We don't yet narrow the else clause on account of instanceof; see #1719

@alexeagle
Copy link
Contributor Author

thanks, world-class support! 💐

alexeagle added a commit to alexeagle/angular that referenced this issue Oct 3, 2015
Note that the previous type of StringMap was overly permissive and didn't catch errors.
Also we have to explicitly type empty objects, which is explained here:
microsoft/TypeScript#5089
alexeagle added a commit to alexeagle/angular that referenced this issue Oct 3, 2015
Note that the previous type of StringMap was overly permissive and didn't catch errors.
Also we have to explicitly type empty objects, which is explained here:
microsoft/TypeScript#5089
alexeagle added a commit to angular/angular that referenced this issue Oct 3, 2015
Note that the previous type of StringMap was overly permissive and didn't catch errors.
Also we have to explicitly type empty objects, which is explained here:
microsoft/TypeScript#5089

Closes #4487
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants