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.
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.
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()
I know the review period is over but I waited on responding to see if others have additional input.
I have tried multiple different names throughout the multi-year duration of this particular new API. While doing so, I came across many different types that we might want to have in the future, and I personally feel that being explicit here is better than potentially having future confusion. We might want to have types that support any given combination of multi/single on each side, i.e.:
Coming up with distinct and clearly recognizable names for all of those is hard. I was also looking at what other languages do, and I found Tokio's mpsc channel really fitting as a name. Since we don't do abbreviations in Swift, I felt that the long form of that name is a good fit.
I experimented with the explicit factory type a bit more, and it made deconstruction of the source and the channel a lot more complicated due to how deconstruction of @frozen ~Copyable types work. Having said that, I think we could pull it off, but it would require another type as part of the API.
Here’s one scheme that I think is both explicit and terse:
And, thinking about it a little, I think it’s not unprecedented either.
After taking some time to review this; I am inclined to accept the proposal as-is; the concerns about naming are reasonable but not horribly impactful since this is definitely a specialized tool, and having a specialized name is par for the course. The splitting of the source type also seems to be perhaps too much involved modification to pull that off.
This will be merged and integrated into the next release.