Suggestion: treat `in` operator as type guard which asserts property existence

[jcalz]

TypeScript Version: 2.8.0-dev.20180204

Search Terms: in operator type guard generic assert

Code

function f<K extends string, T extends object>(key: K, genericObj: T, concreteObj: {foo: string}) {
  if ('a' in concreteObj) {
    concreteObj.a / error, Property 'a' does not exist on type 'never'.
  }
  if ('a' in genericObj) {
    genericObj.a / error, Property 'a' does not exist on type 'T'.
  }
  if (key in concreteObj) {
    concreteObj[key]; / error, Type 'K' cannot be used to index type '{ foo: string; }'
  }
  if (key in genericObj) {
    genericObj[key] / error, Type 'K' cannot be used to index type 'T'.
  }
}

Actual behavior:
The compiler does not recognize that the objects have relevant keys even after checking for the existence of the key with the in operator. According to a comment by @sandersn, the in type guard (as implemented in #15256) narrows by eliminating members from a union; it does not assert that a key exists.

Desired behavior:
The compiler would assert that each object had a property with the relevant key, after having checked for the existence of the key with the in operator. Note that one possible implementation of an asserting type guard would look like

function inOperator<K extends string, T extends object>(k: K, o: T): o is T & Record<K, unknown> {
  return k in o;
}

but this does not behave exactly as desired, possibly due to the bug in #18538: (not sure if #18538 was officially fixed, but it's not erroring anymore)

function g<K extends string, T extends object>(key: K, genericObj: T, concreteObj: { foo: string }) {
  if (inOperator('a', concreteObj) {
    concreteObj.a / okay
  }
  if (inOperator('a', genericObj) {
    genericObj.a / okay
  }
  if (inOperator(key, concreteObj) {
    concreteObj[key]; / okay
  }
  if (inOperator(key, genericObj) {
    genericObj[key] / okay
  }
}

If a fix for #18538 appears and makes the g() function compile without error, great. Otherwise, maybe the property assertion for in could happen some other way. Not sure.

Playground Link: Here

Related Issues:
#10485, Treat in operator as type guard
#15256, Add type guard for in keyword
#18538, Error when mixing keyof and intersection type and type variable (fixed?)

(EDIT: #18538 seems to be fixed)
(EDIT: change any to unknown)

[mhegazy]

related discussion also in #10715 about type guards "evolving" the type of an expression.

[GregRos]

This! Currently, we have the odd situation that when you write:

if ("assign" in Object) {
    Object.assign(target, ...args);
}

When the ES6 typings aren't loaded, it will narrow Object down to never in the if statement!

[mhegazy]

@GregRos please see #21517

[GregRos]

@mhegazy Yup, I know. I was giving it as an example for what this suggestion would fix. I know why it's happening.

[mattmccutchen]

Let's add some other ways of asserting property existence from #25720 to this proposal:

let x: unknown;

/ All these should narrow x to {prop: unknown} (s/any/unknown/ from original proposal by Matt)
"prop" in x;
x.prop != null;
x.prop !== undefined;
typeof x.prop !== "undefined";

/ typeof should work on properties of the unknown variable
typeof x.prop === "string"; / should narrow x to {prop: string}

[mhegazy]

Similar requests in #10715, #25720, and #25172

[leighman]

@mattmccutchen I think you'd want those to narrow to {prop: unknown} rather than {prop: any} wouldn't you?

[felipeochoa]

@mattmccutchen The problem is that trying to access a property on null/undefined will throw an error at runtime. I would support adding those type guards, but only on the object type. (If there were a way to get an unknownWithoutNullOrUndefined type, that would be even better)