Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a higher arity version of merge(…) #218

Open
tonyarnold opened this issue Oct 19, 2022 · 3 comments
Open

Provide a higher arity version of merge(…) #218

tonyarnold opened this issue Oct 19, 2022 · 3 comments
Labels
Future Unscheduled work for future releases

Comments

@tonyarnold
Copy link

I've got a use case where I have an unknown number of AsyncChannels that I want to merge into a single stream of events.

It'd be wonderful if merge(…) and friends supported more than an arity of 3 - ideally accepting a sequence?

Thanks!

@twittemb
Copy link
Contributor

twittemb commented Oct 19, 2022

Hi

from what I know this is something that should arrive when generic variadics are available so we are not constrained to merging the same types of AsyncSequence.

Perhaps there are workarounds in your case. One that comes to my mind is (perhaps not the most efficient though):

Having a task group where you iterate over every channel you have (a task per channel) and send the elements to a single Channel. This “output” channel will act as a merging bus. You can then iterate over this single channel in another task.

@FranzBusch
Copy link
Member

@twittemb Is right here that this is something we ought to be able to do one variadic generics land. My position right now is to avoid adding sequence based APIs since they have a few downsides such as introducing an array allocation which could be avoided.

What I can recommend you for the time being is either of these two:

  1. If merge is last transformation applied to your sequence chain then you can as @twittemb pointed out maybe use a task group and merge from there by just creating a child task for each upstream and calling next on the group repeatedly.
  2. You could copy the code that is used for the implementation of merge and just extend it to whatever arity you need. This involves very minor changes and a bit of code duplication.

@tonyarnold
Copy link
Author

Thanks to you both - that guidance and info is much appreciated.

I'll see if I can work out how to extend the existing code to support different arities in my local project.

I'll also go read up on the parameter packs pitch by Holly and Slava - I'm really excited by this bit of work!

@FranzBusch FranzBusch added the Future Unscheduled work for future releases label Jun 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Future Unscheduled work for future releases
Projects
None yet
Development

No branches or pull requests

3 participants