Stream transformation functions should all accept futures

[nex3]

The Stream API has numerous transformation functions that take blocks, mirroring the Iterable transformation functions. Of these, only mappedBy and reduce allow their blocks to return Futures. It would be more consistent and more useful if all the transformation functions worked with asynchronous blocks.

[madsager]

cc @floitschG.
Removed Area-IO label.
Added Area-Library label.

[lrhn]

I don't see mappedBy or reduce accepting Futures either (they accept futures as any other value, but don't treat them specially).

The problem with handling futures is that it isn't obvious what to do about them
You can either pause the incoming stream until the future completes, and then use the result as the next stream event, or you can just let the original stream continue report the future results in the order they complete in (that is, not necessarily preserve the order of the original events). Both makes sense in different cases.

[nex3]

You're right, I misread the lack of type annotations to indicate that they could return Futures.

The driving use case here isn't map/reduce (where it sometimes makes sense to return literal Futures rather than resolving them) but other methods that return e.g. booleans or ints, such as filter(), any(), or max().

[nex3]

Added Library-Async label.

[lrhn]

Removed Type-Defect label.
Added Type-Enhancement label.