AsyncAlgorithms: MultiProducerSingleConsumerAsyncChannel

Evolution Discussion
1

Hiya folks!

The review of MultiProducerSingleConsumerAsyncChannel for AsyncAlgorithms begins now and runs through Nov 5th, 2025.

This review is a bit less formal than the full Swift review process. That being said if you have any feedback that needs to be shared privately please contact me directly via DM.

19 Likes
2

Looking very nice!

I know the name was iterated somewhat in the pitch phase already, but there’s no discussion in the alternatives considered. I’d still ask if a shorter than six-word-long name could be an option, because MultiProducerSingleConsumerAsyncChannel<Element, any Error> is going to take a serious amount of attention from any ordinary type signature.

Given that the type’s use of ~Copyable makes it impractical to share the consuming side, would it make sense to just omit the middle two words, leaving us with MultiProducerAsyncChannel? And to cut a few more characters, we could reuse the term source for referring to the producer, yielding MultiSourceAsyncChannel.

Yet another option would be SharedSourceAsyncChannel, making it clear what can be shared.

One more alternative would be to look at it from the other point of view: the existence of AsyncChannel as a multi-producer/multi-consumer channel suggests “multi” to be the default, leaving us with something like SingleConsumerAsyncChannel. I think I still like MultiSourceAsyncChannel most.

6 Likes
3

Not as the review manager but instead my personal views:

I think this thing is definitely a specialized tool and those specialized tools having very explicit names (and even very lengthy names) is not a drawback but instead a feature - it does what it says on the tin. Granted perhaps it might be more so named instead around its use than its behavior - e.g. it is seemingly intended to be a channel for external back pressure so perhaps that as a root of naming might be more smooth rolling of the keyboard? If the name is accepted as is: personally I am fine with that.

There is however one area that I did notice re-reading the proposal:

let channelAndSource = MultiProducerSingleConsumerAsyncChannel.makeChannel(
    of: Int.self,
    backpressureStrategy: .watermark(low: 2, high: 5)
)
var channel = consume channelAndSource.channel
var source1 = consume channelAndSource.source
var source2 = source1.makeAdditionalSource()

it almost seems that the first source (in the example source is given some sort of syntactic preference. Would it be possible to have that source instead be a factory that makes additional sources?

let channelAndFactory = MultiProducerSingleConsumerAsyncChannel.makeChannel(
    of: Int.self,
    backpressureStrategy: .watermark(low: 2, high: 5)
)
var channel = consume channelAndFactory.channel
var source1 = channelAndFactory.factory.makeSource()
var source2 = channelAndFactory.factory.makeSource()

This obviously goes head first into the ~Copyable/~Escapable 'ness of the type. But a small change in that direction could help make things slightly more understandable/approachable perhaps.

It could even go further: that the factory method could even be hoisted into the channelAndFactory type in that example (either as the only interface or a funnel for common use):

let channelAndFactory = MultiProducerSingleConsumerAsyncChannel.makeChannel(
    of: Int.self,
    backpressureStrategy: .watermark(low: 2, high: 5)
)
var channel = consume channelAndFactory.channel
var source1 = channelAndFactory.makeSource()
var source2 = channelAndFactory.makeSource()
1 Like