Check receiver

[mhofman]

Other constructor functions use the receiver, in general to create a new promise capability.

Unlike these other functions, .isPromise synchronously returns a boolean, and does not need to create a new promise capability.

The question is whether to use the receiver to more closely mimic the check Promise.resolve() does. This is definitely acceptable if tc39/ecma262#3689 is accepted as that extra check would remain non-observable (as long as the caller trusts the receiver).

The extra check (whether the current .constructor or the proposed __proto__ check) is straightforward to implement in user land, so there is little motivation to include it, just better alignment between Promise.isPromise and Promise.resolve (aka that the former implies the latter is an identity operation).

We could also implement a check based on the receiver only if one is provided (aka called as function vs method).

[bakkot]

I feel pretty strongly that this should be the precise equivalent of the IsPromise AO. Any other checks you want to do you can do yourself.

[mhofman]

I tend to agree. Was just highlighting a difference with other constructor "static" methods, in particular resolve.