Add Source.mapStateful and Source.mapStatefulConcat combinators

[rucek]

I'm not sure whether f should return (S, Option[U]) or (S, U) - where in the former case the Option indicates whether anything should be sent downstream.

The former is more flexible, but introduces additional complexity to the signature. Comparing to Akka Streams, the current approach mixes statefulMap and statefulMapConcat a bit, in that you can control whether the result of f will be sent downstream at all. However, unlike in Akka Streams, f can only return an Option, not an Iterable (which is flattened in Akka's statefulMapConcat).

Any thoughts on this (or anything else in the proposed approach)?

[rucek]

Also, any ideas for more test cases are welcome 😄

[adamw]

I think that the akka streams approach might make sense - a general mapStatefulConcat, and a special-case, simplified mapStateful?

[rucek]

See #18 (comment) for a discussion about checking isValue after send().

[adamw]

I think here we already have the desired error handling, so no changes should be necessary :)

[rucek]

We're still checking the result of c.send below in result.iterator.map(c.send).forall(_.isValue), although we assume that send should not fail since we control c, so we should probably always return true after sending, right?

[adamw]

right, though this at worst is dead code - not that there's a possiblity of incorrect behavior. We can change this though:

• ignoring the return value probably needs a comment that we know what we are doing - and why
• in larger code chunks (which are harder to follow), we might opt for the defensive solution anyway