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

Narrow "string" to "keyof T" with "in" guard? #12892

Closed
danvk opened this issue Dec 13, 2016 · 6 comments
Closed

Narrow "string" to "keyof T" with "in" guard? #12892

danvk opened this issue Dec 13, 2016 · 6 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@danvk
Copy link
Contributor

danvk commented Dec 13, 2016

Should if (x in t) {} narrow the type of x to be keyof T inside the conditional block?

TypeScript Version: 2.1.4

Code

interface Spec<T> {
  description: string;
  default: T;
}
function getDescription<T>(specs: {[k in keyof T]: Spec<T[k]>}, k: string) {
  if (k in specs) {
    return specs[k].description;
    // error TS2536: Type 'string' cannot be used to index type '{ [k in keyof T]: Spec<T[k]>; }'.
  }
  return null;
}

Expected behavior:

This should type check. k should be narrowed from string to keyof T inside the if (k in specs) guard.

Actual behavior:

The type of k remains string inside the guard, leading to the indexing error.

@RyanCavanaugh RyanCavanaugh added In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Dec 13, 2016
@zpdDG4gta8XKpMCd
Copy link

zpdDG4gta8XKpMCd commented Dec 13, 2016

yes it should as it was proven at runtime to be true

(maybe not keyof T itself, but something that extends keyof T)

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Dec 14, 2016

@Aleksey-Bykov It is actually not something that extends keyof T; it's the opposite, and keyof T is the lower bound. Adding more elements to the union will make it a supertype (i.e. a less-specific type).

@zpdDG4gta8XKpMCd
Copy link

true, i always forget that unions are the other way around

@mhegazy
Copy link
Contributor

mhegazy commented Jan 23, 2017

You can capture the type of specs as a generic type, and constraint k to be keyof that. if you still want to drill in and get a property type you can use lookup types, e.g.:

export interface Map<T> {
  [x: string]: T
}

interface Spec<T> {
  description: string;
  default: T;
}

function getDescription<S extends Map<Spec<any>>, K extends keyof S>(specs: S, k: K) {
  if (k in specs) {
    return specs[k].description;
    // error TS2536: Type 'string' cannot be used to index type '{ [k in keyof T]: Spec<T[k]>; }'.
  }
  return null;
}

For getting the type of default, for example, you can write it as such:

function getDefault<S extends Map<Spec<any>>, K extends keyof S>(specs: S, k: K): S[K]["default"] {
  if (k in specs) {
    return specs[k]["default"];
    // error TS2536: Type 'string' cannot be used to index type '{ [k in keyof T]: Spec<T[k]>; }'.
  }
  return null;
}

getDefault({ x: { description: "s", default: 1 } ,y: { description: "s", default: "ss" } }, "x"); // number
getDefault({ x: { description: "s", default: 1 } ,y: { description: "s", default: "ss" } }, "y"); // string

@mhegazy mhegazy removed In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Jan 23, 2017
@mhegazy
Copy link
Contributor

mhegazy commented Jan 23, 2017

The reason why narrowing is not really correct is S can have more properties at runtime than we know about at design time. so if we narrow k to keyof specs it would be more restrictive than users intend.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jan 23, 2017
@danvk
Copy link
Contributor Author

danvk commented Jan 24, 2017

Thanks for the explanation, @mhegazy

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

5 participants