The term "flatten" or "flatmap" has also been used to refer to "flattening"
a nested array; and/or "flattening" (output) of a potentially (arbitrarily)
nested data structure (synchronous and asynchronous input/output).

"easier to read" is subjective; depends on the expectations of the reader.
try..catch blocks could be considered explicitly "easier to read" by the
names used: "try"; "catch".

The requirement appears to be a "reflect" pattern? E.g., see this answer
https://stackoverflow.com/a/31424853 at Wait until all ES6 promises
complete, even rejected promises

const reflect = p => p.then(v => ({v, status: "fulfilled" }),
                            e => ({e, status: "rejected" }));

reflect(promise).then((v => {
    console.log(v.status);});

Is the expected result to write less code and handle exceptions implicitly?

On Tue, Apr 23, 2019 at 8:25 PM Aaron Silvas <aaronsilvas at gmail.com> wrote:

> https://github.com/asilvas/proposal-promise-flatten
>
> Looking for interest, and TC39 champion.
>
> The basic idea is to provide a simpler, more consistent interface, and
> easier to read code over using try/catches for async code paths. Regardless
> of which errors are handled or ignored, it's treated as nothing more than
> another input in the result, not all that dissimilar to callbacks.
>
> async function test(promise1, promise2, promise3) {
>   const [, val1] = await promise1.flatten(); // ignore exceptions
>   const [err, [val2, val3] = []] = await Promise.all([promise2, promise3]).flatten();
>
>   if (err) throw err; // throw to caller
>
>   return val1 + val2 + val3;
> }
>
>
> Original topic that spurred interest in this pattern:
> https://twitter.com/DavidWells/status/1119729914876284928
>
> Spec discussions:
> https://twitter.com/Aaron_Silvas/status/1120721934730137601
>
>
> Thanks,
>
> Aaron
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190424/74b3cd20/attachment-0001.html>

The term "flatten" or "flatmap" has also been used to refer to "flattening"
a nested array; and/or "flattening" (output) of a potentially (arbitrarily)
nested data structure (synchronous and asynchronous input/output).

"easier to read" is subjective; depends on the expectations of the reader.
try..catch blocks could be considered explicitly "easier to read" by the
names used: "try"; "catch".

The requirement appears to be a "reflect" pattern? E.g., see this answer
https://stackoverflow.com/a/31424853 at Wait until all ES6 promises
complete, even rejected promises

```js
const reflect = p => p.then(v => ({v, status: "fulfilled" }),
                            e => ({e, status: "rejected" }));

reflect(promise).then((v => {
    console.log(v.status);});
```

See also https://github.com/tc39/proposal-promise-allSettled.

Is the expected result to write less code and handle exceptions implicitly?

The term "flatten" or "flatmap" has also been used to refer to "flattening"
a nested array; and/or "flattening" (output) of a potentially (arbitrarily)
nested data structure (synchronous and asynchronous input/output).

"easier to read" is subjective; depends on the expectations of the reader.
try..catch blocks could be considered explicitly "easier to read" by the
names used: "try"; "catch".

The requirement appears to be a "reflect" pattern? E.g., see this answer
https://stackoverflow.com/a/31424853 at Wait until all ES6 promises
complete, even rejected promises

```js
const reflect = p => p.then(v => ({v, status: "fulfilled" }),
                            e => ({e, status: "rejected" }));

reflect(promise).then((v => {
    console.log(v.status);});
```

Is the expected result to write less code and handle exceptions implicitly?