What about Error family?

[micnic]

Should EvalError.isEvalError(), RangeError.isRangeError(), ReferenceError.isReferenceError(), SyntaxError.isSyntaxError(), TypeError.isTypeError() and URIError.isURIError() be also part of this proposal?

[zloirock]

I'm not sure about it. It's just subclasses of Error with the same [[ErrorData]] internal slot.

[jasnell]

These, I think would be quite a bit harder, and a similar check can be done simply by calling (for instance) Error.isError(err) && err.name === 'RangeError'

[ljharb]

I think the proposal will be much simpler if it serves to expose boolean-returning methods that do brand checks - ie, check for the presence of an internal slot. That means it could detect Typed Arrays but not tell you which one is which, and the same for Errors.

[doodadjs]

Maybe a single "is" function with the constructor passed as argument ?

Object.is("", String)   // true
Object.is(1, Number)   // true
Object.is(new TypeError(), Error) // true
Object.is(new TypeError(), TypeError) // true
// ...

[ljharb]

@doodadjs nope, that's a non-starter, since constructor comparisons won't work cross-realm (like iframes etc). That's the primary reason instanceof isn't viable.

[ljharb]

(Separately, Object.is already exists to expose the spec operation SameValue)

[doodadjs]

@ljharb Yeah, I know. I mean by using internal slots (if that's possible).

EDIT: That could be "Object.check" or another name.

[ljharb]

Error is a function and does not have an [[ErrorData]] internal slot - and there's no way to know if a given function would or would not imbue any particular internal slots.

[jasnell]

I believe the current proposal handles this adequately