My point is that perhaps this is something we should consider holistically.
Subject's may appear complex on the surface, but perhaps that's because they solve multiple problems in a single-shot:
- Performing the Source Sequence role
- Multicasting unicast source sequences/pipelines (including conversion of custom unicast
AsyncSequencetypes to be multi-cast) - Side-stepping the multi-pass
AsyncSequenceissue
My concern is that if we continue down the path of solving only no. 2, we will slowly move away from solving no. 1 and no. 3.
My opinion is that there seems to be an attachment to the API of AsyncStream, and particularly breaking apart the 'producer' and 'sequence' parts, similar to the discussion about enhancing AsyncStream with a new initialiser, in the name of simplicity. However, the alternative seems to be many more types with limited composability. So far, I'm not sure this is a progression of the benefits provided by a Subject like type, and to me it feels even more complex.
For example, now programmers must remember that they always need to chain a broadcast sequence to their asynchronous sequence pipelines if they wish to vend to an unknown number of consumers. Worse, if the sequence is type erased (any AsyncSequence), they'll need to do this defensively to avoid undefined behaviour.
Of course, a Subject equivalent would need to be carefully designed to leverage the unique properties of AsyncSequence (i.e. autoconnect doesn't make much sense in the context of a back pressure supporting pipeline), but on the whole, my guess is the surface complexity of Subject will result in a net reduction in complexity when viewed holistically and compared to the current direction.
Hope this is helpful – happy to discuss any of the points raised in further detail if useful.