Open question: Promise[Symbol.matcher]

[ljharb]

(from #263)

Currently, it uses the IsPromise AO, just like Promise.resolve does.

Should we loosen this to also accept thenables?

[ljharb]

My personal opinion is no. With the current semantics:

match (value) {
  when (Promise) { /* real Promise */ }
  when (Promise | { then: Function }) {/* thenable */ }
}

With loosened semantics:

function isPromise(value) {
  const p = Promise.resolve(p);
  p.then(() => {}, () => {}); // to avoid unhandled rejections
  return value === p;
}
match (value) {
  when (Promise) if (isPromise(value)) { /* real Promise */ }
  when (Promise) {/* thenable */ }
}

The latter seems much worse to me than the former.

[theScottyJam]

I would agree here - I would expect to be able to write code like this, and for it to just work:

async function doThing(value) {
  return match (value) {
    when (${Promise}): value.catch(...)
    default: value
  }
}

It would be odd if someone could pass in a then-able and have this function crash because the thenable doesn't implement a .catch() method.

Plus, it's trivial to check if something is a thenable if that's really what's wanted, as you just showed.

[Jack-Works]

Maybe we can try to convert a then-able to a Promise.

Promise[@@matcher] = function (value) {
    const f = value.then
    if (typeof f !== 'function') return { matched: false }
    return { matched: true, value: Promise.resolve(value) }
}

[ljharb]

What would be the benefit? If they want a real promise, they'll Promise.resolve the thenable, or just await it, no?

[tabatkins]

Also agree on no - it would be surprising if Promise, alone among the built-ins, accepted random objects that weren't Promise objects.

If authors want to handle thenables they can do so themselves. The thenable-handling should be considered a legacy-compatibility thing (we did it to help early adoption, as it gave us compatibility with userland Promise libraries), and not something we care about going forward except for consistency in some cases.

[ljharb]

cc @mpcsh @DanielRosenwasser @rkirsling @codehag; any thoughts? If we have consensus on "no" then this can be closed by removing the TODO in the spec.

[rkirsling]

I also agree with "no". 👍