As suggested here, there is now an ongoing pitch aiming to ease the instantiation of an AsyncStream -> [Pitch] Convenience Async[Throwing]Stream.makeStream methods - #30 by twittemb
As already mentioned here, IMO we will have 2 colliding instantiation/usage paradigms in the standard lib and this lib:
- on the one hand,
AsyncChannel
is an all-in-one type that allows sending and iterating - on the other hand,
AsyncStream
(with this pitch) would separate the sending and iteration mechanisms into 2 distinct types.
IMO AsyncChannel
and AsyncStream
belong to the same family of « bridging » types (allow async communication in an imperative way), and it would make sense to provide a common pattern for their usage, whether it is an all-in-one type for both or 2 types for sending/iterating.
I think that before releasing the v1 of this repo, we have to make a strong statement about that (perhaps AsyncChannel
should be 2 types) so that the future variants of Channel can follow the same path.
@Philippe_Hausler @FranzBusch what do you think ?