'in' should not operate on primitive types

[millsp]

TypeScript Version: 4.1.0-dev

Search Terms:
operator in exception crash unhandled

Code

const hasKey = <A, K extends string | number | symbol>(
    thing: A,
    key: K,
): boolean => {
    return key in thing;
};

hasKey(123, 'hello'); // TypeError exception

Expected behavior:

TS should expect A to be an object

Actual behavior:

TS didn't detect the potential crash

Playground Link: https://www.typescriptlang.org/play?ts=4.1.0-beta#code/MYewdgzgLgBAFgQwgaQKYE8YF4YB4CCANDMjKgB5SpgAmEM0ATgJZgDmMAPjGAK4C2AI1SMuDdEJAAbAHwAKAFAxlMKHFZsAXDCJKVAawzbkhBQEptgkNNQIw2GTADee5Y1RReje4cytV6uwA3AoAviEKiCgYcgCMAEwAzMQA5HCoUlIgKWZBMAD0+TAAKugADqgAooyMIKIUwKhlUMzgCkA

Related Issues:

[DanielRosenwasser]

This is weird because we'd potentially allow String but not string - but that's probably okay.

[DanielRosenwasser]

Approved.

To avoid breakage on unconstrained type parameters, we're thinking to check if the type is assignable to the union of all primitive types - or if it contains any primitive type (e.g. number, string, boolean, bigint, symbol, null, undefined). isTypeAssignableToKind might be one thing to use here, if not, just use isAssignableTo.

If that's still too breaky, maybeTypeOfKind is a helper that can do this pretty quickly.

The more thorough version of this would be to check whether the type on the right side of the in has to be assignable to object. We could run that on the RWC.

[DanielRosenwasser]

To be explicit, this is all about the type on the right of the in operator. The left can be unconstrained, and maybe we should reconsider that at a later date.