You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// `Itertools::get` indexes an iterator:assert_eq!((0..5).get(2).collect::<Vec<_>>(),
vec![2]);assert_eq!((0..5).get(..3).collect::<Vec<_>>(),
vec![0,1,2]);assert_eq!((0..5).get(2..).collect::<Vec<_>>(),
vec![2,3,4]);
I'm excited to merge this—it feels like something that ought to be in the standard library—but I want to avoid another {Itertools,Iterator}::flatten debacle; i.e., if the core library later adopts this same method, then itertools users calling this method will have builds break.
Would this addition be a good fit for the core library?
Sounds awesome. It's similar to python itertools.islice function. But I'd like to use the normal array slicing syntax. After this we need a built-in way to match on iterators, and the basic needs are covered.
Activity
leonardo-m commentedon Jun 18, 2020
Sounds awesome. It's similar to python itertools.islice function. But I'd like to use the normal array slicing syntax. After this we need a built-in way to match on iterators, and the basic needs are covered.
cuviper commentedon Jun 18, 2020
The problem is that operator
Indexonly returns&Output, andIndexMutreturns&mut Output, so you can't create a new value for the indexing result.lachlansneff commentedon Jun 18, 2020
An
IndexableItertrait seems like an interesting idea.