-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Open
Labels
A-iteratorsArea: IteratorsArea: IteratorsC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
Itertools is considering a PR introducing iterator indexing, implemented in the same manner as the core library's slice indexing mechanism. This playground link demonstrates the gist of it:
// `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?
leonardo-m, vultix and Philippe-Cholet
Metadata
Metadata
Assignees
Labels
A-iteratorsArea: IteratorsArea: IteratorsC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.