choose another name that makes it clear we just mean native promises

[michaelficarra]

I understand that this name is meant to mimic Array.isArray and Error.isError because, like Array with magic length and Error with magic stack, native promises have magic await behaviour. But unlike Arrays and Errors, I had to be clear in my previous sentence when I said "native promises". The usage of the word "promise" in the community means not only native promises but also promises from popular promise libraries. Having an isPromise function return false for those just doesn't seem right. I think this concern should override the consistency argument and we should rename this function to something like isNativePromise or isBuiltinPromise or even like hasMagicPromiseShortcuts.

[bakkot]

isNativePromise might also resolve @zloirock's concern in #2.

[mhofman]

My concern is that "native" is currently used in the spec only in relation to errors, and never in any API name. I have colloquially used "native" to described the spec implementation of promises, but given the Promise context here is already the native promise implementation, it didn't seem needed. (same thing for built-in)

A userland implementation of Promise could similarly expose a Promise.isPromise predicate to identify promise instances it is capable of adopting.

Would it be sufficient to rely on documentation like MDN to clarify what this check does, the same way Error.isError documentation clarifies the nature of the check?

[bakkot]

It's true that "native" doesn't currently come up in any API names, but it does come up when stringifying native functions. I think almost all JS developers will have encountered it in this context and that meaning is basically the correct one.

[ljharb]

A non-native Promise is called a "thenable", though - how often do people still encounter non-native Promises at this point?

[zloirock]

I think that it should be called isPromise. And added isThenable for all promises, including non-native.

[ljharb]

I'm not sure why we'd need a method that just does Promise.isPromise(p) && typeof p.then === 'function'.

[mhofman]

I believe @zloirock 's ask is to also introduce an isThenable predicate, but on top of being easily implementable in user-land, such a check is also a bad pattern to follow for thenables, one reason amongst other being that it introduces TOCTOU concerns (see #2 (comment))

[zloirock]

@mhofman, one more time - in case of adding isPromise, I ask adding a full complex of tools for brand checking like isMap, isWeakMap, isDate, etc. - and each of them will be more useful for users than isPromise. In case of promises optimisation - isThenable - and "a bad pattern" is a very controversial statement. Take a look, for example, at a neighboring, Promise.resolve, logic,

What's the difference?

[zloirock]

const p = Object.defineProperty(Promise.resolve(42), 'constructor', { get() { Object.defineProperty(this, 'constructor', { value: Object.defineProperty(function () {}, Symbol.species, { value: function () { console.log('oops') } }) }); return Promise; }, configurable: true });
const t = Promise.resolve(p);
console.log(p === t); // => true
Promise.prototype.then.call(t); // => oops

[zloirock]

Ok, looking at tc39/ecma262#3689, your position is clear.

[mhofman]

The position of most committee members is that most subclassing support through species was a mistake. In the case of PromiseResolve it is doing a sort of species check to restrict which subset of native promises are meant to be adopted instead of assimilated, and one that I consider problematic as it is observable (as you've seen through that issue).

Anyway this leads back to the motivation for a brand check for promises: because the spec treats native promises in non-receiver position specially, I want a way to test whether the object will get this special treatment, as I explained in the readme and in #2.

I am not aware of similar motivations for other built-ins, and brand checks for those would have to be independently brought up in their own proposals.

The question in this thread is regarding the naming, let's keep it on topic.

[rbuckton]

I think that it should be called isPromise. And added isThenable for all promises, including non-native.

To be clear, "thenable" does not mean userland promise. "thenable" means "an object with a callable then". This is an important distinction made in the Promsie/A+ spec that shouldn't be conflated.

For example, { then(x) { return x + 1; } } is a "thenable", but certainly isn't a userland promise.

[zloirock]

@rbuckton, there is no difference is this a real userland promise or not - this answers the question of whether the language mechanisms will try to process it as a promise or not.

[rbuckton]

This test can be accomplished with a simple expression, however, unlike the brand check. I'm not sure a predicate is warranted, and I worry using the term isThenable will cause confusion in the community. I've already had conversations with developers that think "thenable" just means "userland Promise" and I don't want to reinforce that assumption.