-
Notifications
You must be signed in to change notification settings - Fork 3
feat: add typed iterators for StreamMap and StreamSet
#10
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
Conversation
thomaseizinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! I left a few comments with nits.
I don't think this is a breaking change because the docs for Any say:
Most types implement Any. However, any type which contains a non-'static reference does not. See the module-level documentation for more details.
We already require all streams and futures to be 'static so I think we are fine here. Having said that, I don't think it is a big deal either way and we can just also publish another minor release.
| } | ||
| assert_eq!(streams.iter_typed::<mpsc::Receiver<()>>().count(), N); | ||
| for (i, (id, _)) in streams.iter_typed::<mpsc::Receiver<()>>().enumerate() { | ||
| let expect_id = format!("ID{}", N - i - 1); // Reverse order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh? Why are we handing them out in reverse order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why, but that's how the inner SelectAll::iter returns the the elements. Probably an implementation detail of the SelectAll data structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. It is a Vec internally. Should we sort them by ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can sort them in the SelectAll, can we? Or where/ how should we sort them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could sort them as part of the Iterator implementation. itertools has a combinator for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be better left to the caller: callers who want a sorted iterator can use the combinator, and those who don't care don't have to pay the performance cost of sorting/comparisons (and extra temporary memory).
Documenting that the order is unspecified should be enough to inform people of the need for sorting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documenting that the order is unspecified should be enough to inform people of the need for sorting.
Makes sense to me! Wanna send a PR?
|
Awesome! Thanks for pushing this forward. I'll merge this to |
@elenaf9 Let me know once you need a release here. |
This is on my list of things to do, but I don't know how many days or weeks it will be until it reaches the top of the list. So @elenaf9 feel free to go ahead (and close my |
Based on discussion in #8 and draft #9.
Notes
I renamed the functions to
iter{_mut}_typedto avoid confusion with normaliter/iter_mutand emphasize that streams that can't be downcasted will be skipped. Wdyt @thomaseizingerAlso, a major version bump is needed because it breaks the API with the additional
Anybound, right?