Turn sinks into flows

[johanandren]

Many of the sinks provides a materialized future value just to aggregate or signal a single value on completion. What if we made those sinks flows and passed the completion object downstream as an element instead.

source
  .via(FileIO.toPath("/tmp/example"))
  .runForeach(ioResult => 
     println(s"Writing done, wrote ${ioResult.bytes}")
  )

Good aspects

• Can avoid the syntax overhead of having to deal with a materialized value/future/completion stage/execution context
• Can perhaps avoid separate materialization where completion should trigger a new stream
• Could allow those operators to be used in more places as they do not terminate the stream

Less good

• Several options for doing the same thing is confusing
• Kind of weird representing a single value arriving at some point as a stream when we have futures

[patriknw]

I think this idea originated from the recommendations for Alpakka connectors (cc @ennru) where you want to continue with the input elements, or the per element results, or the "commit token" after the connector. I didn't see it as a good option for aggregating sinks.

[ennru]

Flows are more useful than sinks, as even with sinks you often need to react on their materialized value. What users often end up with is running other flow in mapAsync so that the "inner" flow's result value continues downstream.

If we'd offer more of the current sinks in a flow-variant this hopping between flows and futures would not be needed.

I think Flow.fold and Sink.fold is a good example of this suggestion, where the sink is nothing but the flow with a Sink.head.

It might be harder to get the head around this kind of thinking, though. I guess we should collect more examples to see if it would be motivated to invest in this.