Some channel functions have problematic names about libraries HOT 6 CLOSED

I see your point and we will discuss possible changes for the 1.2 release.

from libraries.

Sorry, that I just come now back to this.
So zip should be doing, what join is doing now? So it collects a set of n values from all upstream senders and passes it then to the process, that accepts n parameters? Or do you think, that this process should accept a tuple of n elements?
For the beginning, I would not implement a reduction/join.
So merge then will be parametrized. One option is 'round-robin', 'unordered' and 'zip' would then be the third one?

from libraries.

No need to apologize.

So, zip would strictly be:

zip(channel<T1>, channel<T2>, ...) -> channel<tuple<T1, T2, ...>>

but the option to also support n-ary processes could be cool - haven't checked how you implemented the library, but something like a constexpr-if on std::is_invocable<F, T1, T2, ...> to choose whether to use std::apply or std::invoke (separate tuple args vs pass the tuple as the argument) could do the trick.

And join would be

join(channel<channel<T>>) -> channel<T>

from libraries.

Currently, a channel consists of two ends: a sender and a receiver. Each receiver is associated with a process (e.g. a callable object or an instance of a process that has to implement certain functions.)

I am not that deep in functional programming - I have your upcoming book already on my order list :-) - so would a zip implementation qualify your expectations when it would go like this:

template <typename F, typename... T>
zip(F&& f, receiver<T>, ...) -> receiver<result_of_t<F(T...)>>

where F is a callable object with T... parameters?

Or must F take as argument a tuple<T...>?

from libraries.

Heh, I'm blushing :)

Usually, the zip function generates a series of tuples, and the zip_with calls an n-ary function. If you can not create one transformation that does both through static introspection, maybe zip + zip_with will do the trick (it would make it compatible with range-v3).

from libraries.

Fixed in 1.3.0

from libraries.