pipeAsync should be able to accept Promise as input

[vitaly-t]

At the moment, we have to use toIterable when input is a promise. But for pipeAsync there is no reason not to do so automatically.

Function pipeAsync should allow Promise as input, and automatically call toIterable (internally):

import {pipeAsync, flat} from 'iter-ops';

const p = Promise.resolve([1, 2, 3, 4, 5]);

const i = pipeAsync(p, flat()); // this should just work, without using toIterable(p)

(async function () {
    for await (const a of i) {
        console.log(a); // 1, 2, 3, 4, 5
    }
})();

---

@RebeccaStevens More fun, if you are interested ;)

[RebeccaStevens]

So just took a look at this and it seems really easy to do.
Just a few details we need to sort on how it should work:

• Should it allow any promise or just promises that return an iterable (either sync or async)?
  • Allowing all promise types could be added in as single line (excluding typing updates).
    • Doing so would allow for single values to be used as iterable when returned by promises, but not if they aren't wrapped. If we go with this approach, we'd probably want to allow sync single values as well which would mean we should also make the change to sync pipeline as well.
  • Only allowing promises that return an iterable.
    • This wouldn't be hard either, but it would require some extra checks to be added to test the promise (no more than what toIterable is already doing).

[vitaly-t]

The result of pipeAsync(promise) should be consistent with pipe(toIterable(promise)). If we decide to extend toIterable later, it would be another matter. For now, we should just use the existing toIterable to provide consistent result.

@RebeccaStevens ;)

[RebeccaStevens]

What I'm getting at is the current toIterable supports more than just making promises iterable. It will also make single values into an iterable of one value.

If we simply use toIterable, we will be getting promise support but also other stuff; this would then make pipeAsync inconsistent with pipeSync.
Should pipeSync also get support for these other things or would it be better to make pipeAsync not also get that other stuff?

[vitaly-t]

You are right, there would be inconsistency, I forgot about simple values.

I think it is better then to close this issue, leave functionality as is, we do not want to create a discrepancy here.