Philippe Hausler

The cancellation mechanism is handled on the other side of the channel, not the emitter side. If the consumer cancels, then the send will resume immediately. Is the aim here...

So we can control the spawning of tasks! https://github.com/apple/swift-async-algorithms/blob/main/Sources/AsyncSequenceValidation/Test.swift#L313 is where the tests do it today - and I could imagine that we could add either extra functionality to that...

I think a more general deadline API is an interesting concept worth investigating; because not just AsyncChannel could benefit from it. Ideally it would need to interoperate with Clock/Instant/Duration; and...

Once the language can support `some AsyncSequence` then the `ReceivingChannel` is just the opaque `AsyncChannel`.

Per the structured versus unstructured case: it only means that the deadline passing and the work child task being cancelled only becomes an issue if that work child task is...

Fantastic! I think this is perhaps one of the first few we should run as soon as we hit 1.0.

@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...

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...

`test_bufferingNewest_error` also fails intermittently

So it is the intent that prior values are NOT buffered for later consumption when new downstreams are attached (else the best case storage would be O(N^2)... which imho is...