Add a proposal for AsyncChannel

[phausler]

This proposal formalizes the AsyncChannel and AsyncThrowingChannel types.

Read the full proposal here.

[twittemb]

Hi @phausler should we consider this https://forums.swift.org/t/asyncchannel-should-we-allow-to-buffer/60876/8 for the v1 ?

[phausler]

@twittemb my initial gut reaction is that the buffering variants should be their own types, provided they need a slightly different interface as you were suggesting?

Now if they can be done with the same interface but just some extra knobs/dials on the initialization then perhaps we can add that as a 1.1 improvement?

Particularly for the channel type I want there to be a very easy on-ramp to more complex functionality; as the programmatic understanding becomes more complex the interface can grow in complexity; leaving the more simple concepts more simple to use and the advanced concepts gradually come at the cost of more advance use.

[twittemb]

@phausler I was seeing the same interface with an init(_:) taking a buffer size with a default value.

The send(_:) would still be async but the suspension would be conditioned by the state of the buffer. It will bring complexity in the internal code yes. Perhaps we could introduce an external state machine concept as we did for merge and zip to help with that.

There is still something I'm not sure of (perhaps you can tell): I'm not sure we can "not suspend" at all if the buffer has slots, or if we have to suspend/resume immediately in an atomic operation.

Let's say that we HAVE to suspend/resume immediately (because of the way concurrency is managed with ManagedCriticalState + Continuations), do we still have a benefit (performance wise) ?

[phausler]

Does it make sense to have the default of the init be the 0 case as we have it?

Per the "not suspend" part: it is 100% reasonable to have an async method that conditionally suspends sometimes and not others; after all that is how the AsyncBufferedByteIterator works.

Do you have any prototypes yet of that? TBH AsyncChannel's internals can definitely be optimized (and simplified I think).

For other reasons I would like to step up our proposals to get to a 1.0 asap. So from a delivery standpoint it makes sense to have that as a future direction.

[FranzBusch]

I left a comment on the forums post. Maybe we can keep the discussion over there to consolidate all views.

[twittemb]

As a reminder @phausler, we opened this issue a while ago (https://github.com/apple/swift-async-algorithms/issues/148) because some cases were hard to test without "inspecting" the internal behaviour of Channels. The issue is tagged v1.0, so I wonder if we want to tackle that now ?

[twittemb]

I've added a reply to the thread -> https://forums.swift.org/t/pitch-async-buffered-channel/59854/8 regarding consistency between AsyncChannel and AsyncStream. @phausler @FranzBusch

[twittemb]

Hey @phausler do you have a take on the AsyncChannel / AsyncStream topic ?

[twittemb]

Hi @phausler can you take a look at https://github.com/apple/swift-async-algorithms/pull/235 where I suggest a new implementation for AsyncChannel?

Thanks.

[soumyamahunt]

The send method doesn't return the reason for completion, and the producer have no information on what happened to the sent value. For example, yield method on AsyncStream's continuation returns an YieldResult.

Returning similar result based on the return reason:

• cooperative cancellation
• channel termination
• sent value consumed

will help community to use channel building custom data structures.

[FranzBusch]

This proposal has been accepted. So merging this PR.