Open question: Promise[Symbol.matcher] #264

Activity

1. ljharb

   added

   question

   champion group discussion

   on Jul 8, 2022
2. ljharb commented on Jul 8, 2022

   

   ljharb

   on Jul 8, 2022

   MemberAuthor

   More actions

   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.
3. theScottyJam commented on Jul 8, 2022

   

   theScottyJam

   on Jul 8, 2022

   Last edited by theScottyJam

   Contributor

   More actions

   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.

   👍React with 👍1Reacted by Jordan Harband
4. Jack-Works commented on Jul 8, 2022

   

   Jack-Works

   on Jul 8, 2022

   Member

   More actions

   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) }
   }
5. ljharb commented on Jul 8, 2022

   

   ljharb

   on Jul 8, 2022

   MemberAuthor

   More actions

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

   👍React with 👍2Reacted by Bo Lingen and Caleb Jasik
6. tabatkins commented on Jul 11, 2022

   

   tabatkins

   on Jul 11, 2022

   Collaborator

   More actions

   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.

   👍React with 👍6Reacted by Jordan Harband, Ross Kirsling, Bo Lingen, Caleb Jasik, Krzysztof Maczyński and Alex
7. ljharb commented on Jul 11, 2022

   

   ljharb

   on Jul 11, 2022

   MemberAuthor

   More actions

   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.
8. rkirsling commented on Jul 11, 2022

   

   rkirsling

   on Jul 11, 2022

   Member

   More actions

   I also agree with "no". 👍

   👍React with 👍1Reacted by Jordan Harband
9. tabatkins

   closed this as completedin #293on Mar 18, 2024