-
Notifications
You must be signed in to change notification settings - Fork 304
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
with_prev
#771
base: master
Are you sure you want to change the base?
with_prev
#771
Conversation
I know it's different but it's quite similar to |
Yes. We did consider that right before deciding to write this one. |
I don't see a situation where I would prefer |
+1 to skepticism about the homogeneity of this, and how frequently it'd be specifically useful vs just phrasing it via https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.scan or something. I guess one option would be to have it be an iterator over enum Window2<T> {
First(T),
Pair(T, T),
Last(T),
} or that could be const-generic extended to Would be good to see more motivation of what would want to use this. |
I'm currently going through all issues, this is similar to #319. |
Alrighty. Our use case is the Exercism Rust track exercise Acronym. Here's our solution (see We felt that For this exercise, we only ever needed a single previous item. If you guys feel that |
Co-authored-by: Warren Wise <[email protected]>
In the case of that exercise, the primary subject of iteration is the current Using For example, with Who calls the shots 'round 'ere? |
I'm fairly convinced that this useful. I do think we need to generalize it to an arbitrary number of previous elements. I also think we could use const generics here — the item type being |
I would say, in that order: bluss, jswrenn, then phimuemue and (since a week) myself. To answer the rest a bit, I surely see the appeal of your proposition. But I think we should consider generalizing that to more than two items, which might be uneasy. EDIT: I guess it mostly depends on the item type we want. |
Hi there, just my two cents: I see that "filling up" the tuples up to a certain length and then keeping the length (as I.e. I wonder whether we - if we include
In my book , both of them are equally useful. As for |
I guess About types, I guess our options are (N meaning might change between types)
|
Sure. Totally. Which made us think of something like this: // with 2 previous and 1 next
let it = [0, 1, 2, 3, 4].with_around::<2, 1>();
itertools::assert_equal(
it,
vec![
(None, None, 0, Some(1)),
(None, Some(0), 1, Some(2)),
(Some(0), Some(1), 2, Some(3)),
(Some(1), Some(2), 3, Some(4)),
(Some(2), Some(3), 4, None ),
]
); But there's a difference in bounds between previous and next. In parallel, we will contemplate the separate
Fixed length of 1. No deal.
After a
Similar to the previous, except for an
Since we are talking about a compile-time We guess this is the reasoning behind
We do see an inconvenience here.
We don't know the policy around dependencies. This option does enjoy the compile-time
We suppose the most important criteria is pattern matching. And we haven't shown such examples, yet. Any feedback at this point? |
"either" is a dependency that does not evolve anymore, and is maintained by bluss (itertools owner). It won't make breaking changes. Basically, we want dependencies to not cause us trouble. And in practice, we can do a lot without them, don't you think? There is a pull request about lending iterators where there was discussion about adding a dependency where I learnt a few things if you want to know more. The most important point here is that the generalization would be either using tuples with some macros (to handle multiple tuple lengths) OR more likely need const generics (like using 2,1 in Personally, I'd like to first focus on improving existing iterators. I've contributed to finish size hints (helpful to avoid reallocations). I'd like to focus on issue 755 at the moment since specializing EDIT: |
This seems generally useful enough to us.
Does anyone feel that we should attempt to contribute this to
Iterator
first?Co-authored-by: Warren Wise [email protected]