compile error in 2.7 for indexed types work with generics

[tommytroylin]

TypeScript Version: 2.7.1

Search Terms: typer inference, indexed types, generics

Code

type Foo = {
  [name: string]: string[] | undefined;
};

const foo: Foo = {};
function bar<SomeName extends string>(name: SomeName): void {
  foo.any!.concat(); // ok
  foo[name]!.concat(); // Property 'concat' does not exist on type 'Foo[SomeName]'
  const newFoo = foo[name]; // ok
  newFoo!.concat(); // ok em....
}

with tsconfig (removed other configs)

{
  "compilerOptions": {
    "esModuleInterop": true,
    "strict": true,
    "strictPropertyInitialization": false
  }
}

Expected behavior:
No Error in 2.7 & 2.6

Actual behavior:
No Error in 2.6
but in 2.7 it throws Property 'concat' does not exist on type 'Foo[SomeName]'

FYI. I found some ways to make this error disappear. I think there must be something related but I can't tell.

• remove undefined type in Foo 's value
• use a temp var to avoid directly usage like const newFoo = foo[name]
• remove generics and define param name to be string

[tommytroylin]

confirmed it exists on version 2.8.0-dev.20180201

[ajafff]

Maybe related to #21368

[mhegazy]

looks like a duplicate of #21369

[tommytroylin]

@mhegazy

I 've read your post on #21369

With that in mind, previously, in TS 2.6 and before, the logic for getting a constraint on a indexed access type was if it has an index signature, then use that, otherwise it was any. In the example above, o[k] was constrained to any, then applying the null assertion operator had no effect, and thus was assignable to string in that case. That means that also take(o[k]) would have been permissible.

but it's not the same case i think.

in ts 2.6.2, the compiler seems to be able to infer that type correctly, not any but string[]

like Foo[SomeName] => string[] | undefined => null assertion operater => string[]

in ts 2.7.1 with a bit smarter compiler, nothing . xD

like Foo[SomeName] => string[] | undefined => null assertion operater => string[] | undefined

BTW, I notice that you labeled #21369 with break change. Is it means won't fix and will document it ? (Nothing related to that issue, just break change label.)

[tommytroylin]

playground
should turn on strictNullCheck as well

[tommytroylin]

considering

• error still exists when replacing undefined with null
• error disappears when strictNullChecks turned off
• error disappears when using a temp var (maybe forcing to do a type inference?)

In my opinion, it's a bug in type system

@mhegazy
any updates on this issue?

[Jessidhia]

This seems to be a problem with the non-null assertion operator when used on the result of a computed member expression. This problem was not present on 2.7.0-rc; seems to be new to 2.7.1.

import * as types from './types'

interface PreloadTypes {
  post: types.PreloadPostData
  user: types.PreloadUserData
}

interface GlobalPreload {
  post?: { [id: string]: PreloadTypes['post'] }
  user?: { [id: string]: PreloadTypes['user'] }
}
declare var preload: GlobalPreload

export function getPreload<TKind extends keyof PreloadTypes> (kind: TKind, id: string): PreloadTypes[TKind]|undefined {
  if (kind in preload && id in preload[kind]) {
    return preload[kind]![id]
    // [id] access errors because it's indexing a possibly undefined object
  }
}

Changing the line to, for example, be preload.user![id] does not produce an undefined object access error.

Changing the access to be

const kindPreload = preload[kind]!
return kindPreload[id]

instead still causes a build error on the second linke because kindPreload may be undefined, despite the typeof kindPreload correctly showing up as GlobalPreload[TKind] on hover type info. It's only when it is then indexed that the | undefined shows up.

Finally, adding the ! on the [id] access when it's split into multiple vars works -- return kindPreload![id] will compile.

Also note that removing the ! from preload[kind]! does not produce | undefined on the typeof kindPreload; in fact leaving it in there triggers tslint's no-unnecessary-type-assertion if you have it enabled.

[typescript-bot]

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