Proposal for Promise.prototype.flatten

Bergi a.d.bergi at
Wed Apr 24 07:07:54 UTC 2019


I oppose this proposal.

In my opinion, mixing normal exceptions (promise rejections) with
result-error-tuples is rather inconsistent than a more consistent
interface. The only thing it might interface better with are
node.js-style callbacks, but we already deprecated those in favour of
`if (err) throw err;` is reminiscent of this old style, it's no longer
necessary to explicitly re-throw with modern syntax.

It's not even simpler, or better to read. The example you gave could
easier be written as
async function test(promise1, promise2, promise3) {
   const val1 = await promise1.catch(err => void err); // ignore exceptions
   const [val2, val3] = await Promise.all([promise2, promise3]); //
throw to caller

   return val1 + val2 + val3;
(Notice also that no default value for the destructuring is necessary,
which is a rather error-prone part of your snippet). Using `catch`
forces the programmer into explicitly providing a default value (even if
`undefined`), which could go unnoticed otherwise.
Can you please add an example where using `.flatten()` actually
introduces an advantage?

If one needs a more powerful error handling approach, you should use
`then` with two callbacks. (Getting a try-catch-else syntax
for that would be nice, though).

As already mentioned, the name `flatten` is ill-suited for this method.

If you absolutely need this functionality, use `.then(r=>[,r],e=>[e])`
in your code, or put it inside a helper function. (Or use one from  a
library like <>).
We do not need this as a method in the EcmaScript standard.

best regards,

More information about the es-discuss mailing list