I wanted to add a little bit more here: It looks like we've identified quite a few different possible behaviours for what we'd want from a multicasting algorithm in terms of source element consumption. To list just some of those identified so far:
- source consumption at the max rate of the source (no back pressure)
- source consumption at the rate of the fastest consumer (back pressure)
- source consumption at the rate of the slowest consumer (back pressure)
In addition, there's obvious behaviours like history and source iterator retention – which due to the tight level of orchestration required – need to managed in the state of the distributing algorithm to ensure cancellation and contiguous delivery of elements are handled correctly.
This is definitely now feeling like a 'family' of algorithms.
The other thing I wonder – and I would love to here the opinion of @FranzBusch and @Philippe_Hausler on this one – is that we still have a situation where our source algorithms (AsyncStream in the standard library) isn't suitable for multi-pass iteration.
It feels to me we are coming up against some of the same problems the designers of the original reactive programming libraries came up against. Can we solve two problems in one here?
Is it sensible for us to consider that actually, the idea of a Subject shaped type in Swift Async Algorithms and its associated multicast(_:) operator is actually a great way of ensuring 1) we are able to implement a range of different multicasting algorithms depending on the use case, and 2) when people reach for a 'source' algorithm, they have a type that is 'multicast by default' and reflects the behaviour that it seems many programmers already intuit.
I'm definitely open minded to alternative solutions, I just haven't seen one that solves these problems as elegantly, and it would seem a shame to exclude what might be an imperfect solution in the absence of something better.