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

Interface with optional properties is not assignable to indexable type with strict-null-checks #15799

Closed
maghis opened this issue May 12, 2017 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@maghis
Copy link

maghis commented May 12, 2017

I understand this is more a feature request then a bug report :)

TypeScript Version: 2.3.2

Code

const test: { [key: string]: string } = {} as { foo?: string };

Expected behavior:
A type with optional properties should be assignable to an indexable, even if the indexable values do not include undefined.

Actual behavior:

error TS2322: Type '{ foo?: string | undefined; }' is not assignable to type '{ [key: string]: string; }'.
  Property 'foo' is incompatible with index signature.
    Type 'string | undefined' is not assignable to type 'string'.
      Type 'undefined' is not assignable to type 'string'.
@mhegazy
Copy link
Contributor

mhegazy commented May 12, 2017

the type should be const test: { [key: string]: string | undefined } = {} as { foo?: string };.

see #13778 for relevant discussion on why the indexer does not include undefined by default.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label May 12, 2017
@maghis
Copy link
Author

maghis commented May 15, 2017

@mhegazy thanks for the pointer, the for loop on an array use case made it perfectly clear.

Should I close this?

@maghis maghis closed this as completed May 15, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

2 participants