ECMAScript proposal and spec for Promise.isPromise.
Stage: 2
Champions:
- Mathieu Hofman (@mhofman) (Agoric)
It is currently impossible to check whether an object is a native promise without side effects. The usual pattern is to test whether Promise.resolve(val) === val, but in the negative case it creates a new promise resolved from val. Besides the unnecessary allocation, it may also trigger user-code related to the thenable assimilation mechanism.
Code that wants to be defensive, for example avoid synchronous re-entrancy when handling unknown values in async logic, can currently only do so by paying the cost of a tick (Promise.resolve().then(() => val)), even when the value is a safe native promise.
Native promises have their internal state safely adopted when doing await val, and if tc39/ecma262#3689 is accepted, for other promise resolution paths.
instanceof Promise is not appropriate because that checks whether Promise.prototype is in the prototype chain of value, not whether the value passes the the IsPromise checks the spec performs internally.
A new Promise.isPromise predicate that exposes the result of the IsPromise abstract operation.
Error.isError does a similar brand check for native Error objects.
Like Error, Promises are also objects which are better "passed by copy" than proxied through membranes. Furthermore, it is already possible to asynchronously detect whether an object is a native promise or not through Promise.resolve().
A Promise.isPromise predicate would actually let membranes detect promise values which should be recreated on the other side.