in operator: check key/property is valid (using keyof)

[OliverJAsh]

Suggestion

🔍 Search Terms

• in operator
• keyof
• key
• property
• validate

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

When using the in operator K in T, TypeScript should error if the provided key K is not assignable to keyof T.

📃 Motivating Example

const obj = { a: "", b: "" };

// This condition will always be false
const condition = "c" in obj;

declare const obj:
    | {
          name: string;
          age: string;
      }
    | {
          species: string;
      };

// This is a mistake, but it's not caught by the compiler.
const condition = 'nam' in obj;

💻 Use Cases

What shortcomings exist with current approaches?

I've tried to define a has function for this purpose but there are lots of edge cases: https://stackoverflow.com/questions/58749852/typescript-defining-the-in-operator-as-a-function

[MartinJohns]

Note that the in operator is explicitly mentioned as a way to narrow union types in the handbook: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-in-operator-narrowing

[RyanCavanaugh]

This is opposite to the highly-requested behavior requested in #21732, which we just implemented

const obj = { a: "", b: "" };
if("c" in obj) {
  // Works in 4.9 nightly
  obj.c
}

With exact types we could revisit, but we don't have exact types

[OliverJAsh]

@MartinJohns This suggestion isn't going against that, as far as I can see. The narrowing is useful. I just want TS to check that it's a valid key in at least one of the union members, so I can't make silly mistakes.

@RyanCavanaugh I think #21732 is really useful, when we're dealing with a type like unknown or object, but in this case we already have type information about the properties (assuming that the type is exact like you say).

[RyanCavanaugh]

If the object isn't aliased in some way, why are you writing an in check?

[OliverJAsh]

Here's one example:

type Fish = { swim: () => void };
type Bird = { fly: () => void };
type Human = { swim?: () => void; fly?: () => void };

const getType = (animal: Fish | Bird | Human) => {
    // oops, typo!
    if ("flyyy" in animal) {
        return "bird";
    } else {
        return "other";
    }
};

[MartinJohns]

The narrowing is useful. I just want TS to check that it's a valid key in at least one of the union members, so I can't make silly mistakes.

You explicitly mentioned keyof T, which only includes keys common in all union types.

[OliverJAsh]

You're right. I should have said something like "distributive keyof" (type DistributiveKeys<T> = T extends any ? keyof T : never).

[RyanCavanaugh]

I think #21732 is really useful, when we're dealing with a type like unknown or object [...]

Sure, but what you're proposing breaks subtyping linearity: if k in T is valid when T is unknown (or object), it doesn't make sense to say that k in T' is invalid when T' is some subtype of T (which, for unknown, is by definition). There are some places where breaking that linearity makes sense, but they're pretty few and far between IMO.

If you had written

type Fish = { swim: () => void };
type Bird = { fly: () => void };
type Human = { swim?: () => void; fly?: () => void };

const getType = (animal: Fish | Bird | Human) => {
    if ("superman" in animal) {
        return "kryptonian";
    } else {
        return "earthling";
    }
};

there doesn't seem to be an error in this program.

[MartinJohns]

@OliverJAsh You could probably easily write an ESLint rule for this, if you still want it.