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

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.

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.

If possible, I would like to make a PR for this.

Which line should emit error, 1) or 2)?

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

hasKey(123, 'hello');
       ~~~
       2) TypeError exception