Creating race conditions when converting akka streams to fs2 streams is too easy about streamz HOT 6 CLOSED

I like the general idea of exposing the materialized value as FS2 stream instead of providing a callback (which makes composition on FS2 side hard or impossible). But for better symmetry with Akka Sink|Source|Flow plus materialized value what do you think about adding converters like toSinkMat, toSourceMat and toPipeMat returning a tuple containing the converted Sink|Stream|Pipe plus a Stream that emits the single materialized value. For example (in pseudocode):

val (fs2Sink, fs2MatStream) = akkaSink.toSinkMat()
val (fs2Source, fs2MatStream) = akkaSource.toSourceMat()
...

This would allow applications to compose the result tuple elements as they like in FS2. Also, when converting an Akka Source to an FS2 Stream, the Stream element type and the materialized value type usually differ and cannot be combined into a single Stream (unless you use something like Either[A,B] as element type but this has less symmetry to Akka Streams).

The onMaterialization parameter of existing converters toSink, toStream and toPipe could then be removed/deprecated. WDYT?

from streamz.

That's not a bad idea - we can have toFoo(implicit ev: Mat =:= NotUsed) and toFooMat returning the tuple. That sounds like a nice interface!

from streamz.

Sounds good, would be great to see a PR! I'm not sure if toFoo(implicit ev: Mat =:= NotUsed) is too restrictive but we can discuss that in the PR later. Thanks for your useful proposal!

from streamz.

I don't think it's too bad - If there's a used Mat value, I think discarding it should be done explicitly, hence the Discard constant that I'd put in the package object to be imported with the implicits

from streamz.

I have a WIP proposal here: master...Daenyth:matvalue

I'm playing around a bit to see if I can keep the single method name next, while still having the differing return types based on Mat

from streamz.

I don't think it's too bad - If there's a used Mat value, I think discarding it should be done explicitly, hence the Discard constant that I'd put in the package object to be imported with the implicits

Understood. If discarding can be done explicitly than it's fine. I thought users are forced to use toFooMat then. So please ignore my previous concern then.

from streamz.