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)

[RyanCavanaugh]

@jcalz can you highlight the differences between #10485 and what you'd want to happen?

[jcalz]

TL;DR: #10485 narrows by filtering union constituents. This suggestion narrows by adding properties to the type.

In cases where y is not a union type or none of the constituents have an explicit property named x, the test if (x in y) should not try to filter union constituents, but should instead narrow y by intersecting its type with Record<typeof x, unknown>.

---

In #10485, the type of the object you're checking with in is meant to be a union, and the type guard filters that union based on whether the constituents do or do not explicitly have a property of the relevant name:

type A = { w: string, x: number };
type B = { y: string, z: number };
function foo(p: A | B): number {
  if ('w' in p) {
    return p.x; // p is narrowed to A
  } else {
    return p.z; // p is narrowed to B
  }
}

Note that this isn't exactly sound, since you can call

foo({ y: "oops", z: 100, w: true }); 

but the point of property checking on unions is usually to use that property as a discriminant, and the sound behavior would probably annoy the heck out of developers.

---

Compare to the following:

function bar(p: {}): string {
  if ('w' in p) {
    return String(p.w); // error?! ☹
  } else {
    return "nope";
  }
}

It is surprising that after what feels like an explicit test for p.w, the compiler still doesn't know that p.w exists. Worse, p is narrowed to never, probably because of #10485.

What I want to see happen is:

• Only do the narrowing in Treat in operator as type guard #10485 if the type is a union where at least one constituent explicitly features the relevant property (edit: optional properties count as "explicit" also).
• Otherwise (or afterwards), have the x in y check be equivalent to the type guard y is typeof y & Record<typeof x, unknown> (modulo the bug in For object type C, type parameter T and mapped type { [K in keyof T & C]: any }, keyof C isn't assignable to K #18538).

[sirian]

@jcalz This guard doesn't work with partial interfaces

function foo(x: {foo: "bar"} | {toFixed?: () => any}) {
  if (inOperator("toFixed", x)) {
    x.toFixed(); // Error, Object is of type unknown
  }
}

[jcalz]

@sirian Yeah, strictly speaking, all you know is that x.toFixed exists, since a value of type {foo: "bar"} may contain a toFixed property (e.g.,

foo(Object.assign({ foo: "bar" as "bar" }, { toFixed: "whoops" }));  // no error

), but assuming people still want the current behavior in #10485 where we eliminate {foo: "bar"} from consideration as soon as we find a toFixed property, then this suggestion is to apply the inOperator() behavior after that elimination.

So in your case, x would first be narrowed to {toFixed?: () => any} as per #10485 and then to {toFixed: (() => any) | undefined} via something like inOperator()... meaning that toFixed is definitely there but it might be undefined (since ? is ambiguous about whether the property is actually missing or present but undefined.)

If you want a better idea what the behavior would end up being like, try the following complex user-defined type guard using conditional types:

type Discriminate<U, K> = ( U extends any ? K extends keyof Required<U> ? U : never : never ) 
  extends infer D ? [D] extends [never] ? U : D : never
        
function hybridInOperator<K extends keyof any, T>(
  k: K, 
  o: T
): o is Discriminate<T, K> & Record<K, unknown> {
    return k in o;
}

producing:

function foo(x: { foo: "bar" } | { toFixed?: () => any }) {
    if (hybridInOperator("toFixed", x)) {
      x.toFixed(); // error, possibly undefined
      if (x.toFixed) x.toFixed();   // okay
    }
}

Does that seem better?

[sirian]

@jcalz
Better, but there is another problem with type infer. Look at example

function foo(x: { foo: "bar" } | Number | { toFixed?: () => any }) {
    if (hybridInOperator("toFixed", x)) {
        x.toFixed(); // no error. since x resolved as Number
        if (x.toFixed) x.toFixed();   // okay
    }
}

I also tried various type guards. But always found a new counterexample(

Upd. As a quick fix - if you change o is Discriminate<T, K> & Record<K, unknown> to o is Extract<T, Discriminate<T, K>>. then x will be resolved as Number | { toFixed?: () => any }

Upd2.

So in your case, x would first be narrowed to {toFixed?: () => any} as per #10485 and then to {toFixed: (() => any) | undefined}

Not right... toFixed would be narrowed to unknown... Look at example. So and error in #21732 (comment) screenshot was not "object is possibly undefined"

[jcalz]

I don't know how worthwhile it is to come up with a user-defined type guard which exactly mimics the desired behavior of in narrowing, in light of the variety of edge cases. In this case, something weird is happening, since the hybridOperator() returns something like x is Number | { toFixed: undefined | (() => any) }; which is wider than Number. The fact that x narrows to Number inside the then-clause looks like some kind of compiler bug (edit: as per #26551, it is not considered a bug, but it is inconsistent and makes it more difficult to design a perfect type guard). I'd rather not get sidetracked here with that.

The "quick fix" has toFixed as optional, but it should be required... which is why I was intersecting with {toFixed: unknown} in the first place.

re: Upd2, I think you're missing that the suggestion is to apply the inOperator() behavior after the elimination that happens in #10485 ? Not sure if I wasn't clear about that.

[sirian]

@jcalz Maybe add smth like & Pick<Required<T>, K & keyof <Required<T>>>? I'll try to experiment at home )

[sirian]

@jcalz what about this one?

type Discriminate<U, K extends PropertyKey> =
    U extends any
    ? K extends keyof U ? U : U & Record<K, unknown>
    : never;

function inOperator<K extends PropertyKey, T>(k: K, o: T): o is Discriminate<T, K> {
    return k in o;
}

function foo(x: null | string | number | Number | { toFixed?: () => any } | { foo: 1 }) {
    if (inOperator("toFixed", x)) {
        // x is number | Number | { toFixed?: () => any | undefined }
        x.toFixed && x.toFixed();
    }
}

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

[jcalz]

Looks good at first glance!

[sirian]

@jcalz There is a dilemma. how should work typeguard?

function foo(x: {foo?: number} | {bar?: string}) {
    if (inOperator("foo", x)) {
        // x is {foo: number | undefined}
        // or
        // x is {foo: number | undefined} | {foo: unknown, bar?: string} 
    }
}

or in this case:

function foo(x: {foo?: number} | string) {
    if (inOperator("foo", x)) {
        // x is {foo: number | undefined}
        // or
        // x is {foo: number | undefined} |  string & {foo: unknown} 
    }
}

[jcalz]

It should be the first one in both cases, {foo: number | undefined}, as implied by the bulleted list at the bottom of this comment.

[sirian]

@jcalz So if we extract types rather than widen it with additional property - what should be at this examples?

function foo(x: {bar?: number}) {
    if (inOperator("foo", x)) {
        // x is never? so is x.foo not accessible?
    }
}
function foo(x: object) {
    if (inOperator("foo", x)) {
        // x is never? so is x.foo not accessible?
    }
}

[jcalz]

It should be {bar?: number, foo: unknown} and {foo: unknown} respectively, as implied by the same bulleted list. I can't tell if that isn't clear or if you're not reading it. 🤕

• Only do the narrowing in Treat in operator as type guard #10485 if the type is a union where at least one constituent explicitly features the relevant property (edit: optional properties count as "explicit" also).
• Otherwise (or afterwards), have the x in y check be equivalent to the type guard y is typeof y & Record<typeof x, unknown> (modulo the bug in For object type C, type parameter T and mapped type { [K in keyof T & C]: any }, keyof C isn't assignable to K #18538).

[bennycode]

I recently came across this problem:

const person = {
  "name": "Benny"
} as unknown;

if (person && typeof person === "object" && "name" in person) {
  console.log(person.name);
}

I am narrowing person from undefined to an object and afterwards I am checking if name is in person but the "in" type guard doesn't seem to catch that as I am getting the following error:

TS2339: Property 'name' does not exist on type 'object'.

Demo: https://www.typescriptlang.org/play?#code/MYewdgzgLgBADgUwE4XDAvDA3gKBjAIjAEMBbBAgLkICEEwwBPAnAXxmIhgFcwBrMCADuYANw4cASwBmMABSIUaAGTKYURohCzFqMBnSYCIAEYArBMCgEYqwiXI3J+3eACU2PDFCQQAGwQAOj8QAHMFZD1AhwQ3cVYgA

[iugo]

I recently came across this problem:

const person = {
  "name": "Benny"
} as unknown;

if (person && typeof person === "object" && "name" in person) {
  console.log(person.name);
}

I am narrowing person from undefined to an object and afterwards I am checking if name is in person but the "in" type guard doesn't seem to catch that as I am getting the following error:

TS2339: Property 'name' does not exist on type 'object'.

Demo: https://www.typescriptlang.org/play?#code/MYewdgzgLgBADgUwE4XDAvDA3gKBjAIjAEMBbBAgLkICEEwwBPAnAXxmIhgFcwBrMCADuYANw4cASwBmMABSIUaAGTKYURohCzFqMBnSYCIAEYArBMCgEYqwiXI3J+3eACU2PDFCQQAGwQAOj8QAHMFZD1AhwQ3cVYgA

const person = {
  "name": "Benny"
} as unknown;

if (typeof person === "object" && person !== null) {
  const o = person as Record<string, unknown>
  if ('name' in o) {
    console.log(o.name);
  }
}

https://www.typescriptlang.org/play?#code/MYewdgzgLgBADgUwE4XDAvDA3gKBjAIjAEMBbBAgLkICEEwwBPAnAXxmIhgFcwBrMCADuYANw4cASwBmMABRRGiELMQo06TYRAAjAFYJgUAjABkp+MlRgYAQi1huAGycBKbHhihIsEBkvqNpwwAEqGIEgAJgA80EiSYADmADQ8-IIiAHyeMvIA5CTkeTAJMCDuuPj43qhOCAB0TiCJciD1hQiu4visbDhAA

[bennycode]

Thanks for you demo, @iugo. Using the type assertion of as Record<string, unknown> feels a bit like cheating because it makes the typeof check unnecessary. I would like to narrow down an unknown type and by using an assertion I am just overriding the compiler's decision. It's like doing this:

const person = {
  "name": "Benny"
} as unknown as Record<string, unknown>;

console.log(person.name);

[iugo]

Because the data is unknown (such as data returned from a JSON string), we use unknown.

{
  const person = JSON.parse(`{"name": "Benny"}`) as unknown;
  check(person);
}

{
  const person = JSON.parse(`["Benny", 21]`) as unknown;
  check(person);
}

function check(person: unknown) {
  if (typeof person === "object" && person !== null) {
    const o = person as Record<string, unknown>
    if ('name' in o) {
      console.log(o.name);
    }

    if (Array.isArray(person)) {
      console.log(...person);
    }
  }
}

[bennycode]

@iugo it looks like what I asked for will become possible soon! 🤩 #50666

[jcalz]

It's happening!!!

[DetachHead]

#50666 did not fully fix this issue:

I'm marking this PR as fixing #21732 even though it doesn't address the case of key in obj where key is of some generic type.

function f<K extends string, T extends object>(key: K, genericObj: T, concreteObj: {foo: string}) {
  if ('a' in concreteObj) {
    concreteObj.a // no longer an error
  }
  if ('a' in genericObj) {
    genericObj.a // no longer an error
  }
  if (key in concreteObj) {
    concreteObj[key]; // still an error
  }
  if (key in genericObj) {
    genericObj[key] // still an error
  }
}

playground

can this issue be re-opened? or is there a new issue for this?

[lazytype]

@DetachHead How would you expect this to work?

  // `concreteObj` is type `{foo: string}`
  if (key in concreteObj) {
    // `concreteObj` is narrowed to ???
    concreteObj[key];
  }

concreteObj being type {foo: string} doesn't mean that 'foo' is the only key in concreteObj. So let's say in the conditional we narrowed the type of concreteObj down to {foo: string} & Record<K, unknown>. Now there'd be no type error, but it would allow code like this:

function f<K extends string, T extends object>(key1: K, key2: K, genericObj: T, concreteObj: {foo: string}) {
  if (key1 in concreteObj) {
    concreteObj[key2];
  }

This is obviously unsafe, and there's no way in the type system to express that concreteObj has key1 but not key2.

[ehoogeveen-medweb]

Yeah, you'd need a construct like valueof key1 (so that in the 4th case, valueof key1 extends keyof genericObj). Not sure where excess properties would fit into that, though. Either way, noUncheckedIndexedAccess is very difficult to use without something like that (and without something to represent the inferred minimum length of arrays).

[bxt]

I think it does not make sense that TypeScript assumes there are additional properties somehow on an object but also does not allow adding new properties to an object at the same time. Just like an if narrows down a type, adding properties to an object could narrow down the type to objects that also include this property. Consider this example:

const objectWithKnownKeys = {
    a: 1,
    b: 2,
} as const;

// This is an error but maybe it should work and just change
// the type of objectWithKnownKeys to include {c: 3} maybe?
objectWithKnownKeys.c = 3;

const key: string = 'a';

if (key in objectWithKnownKeys) {
    // TypeScript should know here there are no additional keys or allow setting c
    const value = objectWithKnownKeys[key];
}

So maybe the actual bug is that objectWithKnownKeys.c = generates an error? Basically TS2339 should not go off when setting. I can find an old issue #766 about this but related to classes. I would also allow to construct object like this instead of relying on any or Partial<>:

type SomeObject = { a: number, b?: number }
// We have to rely on "any", even Partial<SomeObject> would cause an error later
const initiallyEmptyObject: any = {};
initiallyEmptyObject.a = 1;
if (Math.random() > 0.5) { // or some logic
    initiallyEmptyObject.b = 2;
}
const someObject: SomeObject = initiallyEmptyObject;

But I assume this would be a pretty big change and there would need to be a solution for letting people know when they accidentally create a new property with a typo, so that's your reason why this will probably never be fixed.

[RyanCavanaugh]

there would need to be a solution for letting people know when they accidentally create a new property with a typo

This is the entire crux of it; a computer can't tell whether this code is intentional or not:

const dimensions = { width: 0, height: 0 };
dimensions.widht = 3;

Our experience is that detecting retrospectively-obvious-to-human typos is seen as worth the false positives in other cases. It's why we have type annotations.

[aaroncowie]

there would need to be a solution for letting people know when they accidentally create a new property with a typo

This is the entire crux of it; a computer can't tell whether this code is intentional or not:

const dimensions = { width: 0, height: 0 };
dimensions.widht = 3;

Our experience is that detecting retrospectively-obvious-to-human typos is seen as worth the false positives in other cases. It's why we have type annotations.

Could "as const" be used to detect that case?

const dimensions = { width: 0, height: 0 } as const;
dimensions.widht = 3;

[DetachHead]

if you want to allow adding unknown keys to an object, you can define it like so in the type:

interface Dimensions {
    width: number
    height: number
    [key: string]: number
}
const dimensions: Dimensions = { width: 0, height: 0 };
dimensions.widht = 3; // no error

that's an edge case though, and as @RyanCavanaugh said it's far more likely that assigning an unknown key is an error, which is why it wouldn't make sense to not show an error by default, expecting the user to use as const to opt into the functionality they'd want 99% of the time

[KotlinIsland]

@aaroncowie A subtype could already contain that key with an unrelated type, therefor losing type soundness.

function foo(a: { width: number, height: number }) {
    a.length = "idk"
}
const a = { width: 0, height: 0, length: 0 }
foo(a)
a.length // STRING????? HUUUHHH?????

[SlurpTheo]

@lazytype

function f<K extends string, T extends object>(key1: K, key2: K, genericObj: T, concreteObj: {foo: string}) {
  if (key1 in concreteObj) {
    concreteObj[key2]; // ts(2536): Type 'K' cannot be used to index type '{ foo: string }'.
  }

This is obviously unsafe, and there's no way in the type system to express that concreteObj has key1 but not key2.

I'm not following what's obvious about this issue/thread/example. It makes sense to me that you can't index by key2 as f<"foo" | "BAR", { foo: string }>("foo", "BAR", { foo: "a3" }, { foo: "a4" }) is a type-valid caller of this API.

[lazytype]

It makes sense to me that you can't index by key2

The goal of the comment I was replying to is to be able to index concreteObj by key1 after checking for key1's existence with the in operator. What is "obvious" is that it would be unsafe to index concreteObj by key2 if only checking for the existence of key1. My point is that from the perspective of the type system key1 and key2 are of the same type. So there's no way to model the behavior that concreteObj is indexable by key1 but not key2 in the current type system.