-
Notifications
You must be signed in to change notification settings - Fork 22
Closed
Labels
ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)API Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries
Description
Proposal
Problem statement
Add a convenient IntoIterator
enabled function for chaining two iterators.
Motivation, use-cases
- A similar function already exists
core::iter::zip
(added in Add function core::iter::zip rust#82917) - There are many cases where it can be clearer to use a direct function instead of using the iterator method.
- Particularly useful in the case where you want to prepend to another iterator.
- There is prior art for the utility of this in itertools::chain.
for (x, y) in chain(xs, ys) {}
// vs
for (x, y) in xs.into_iter().chain(ys) {}
Some examples from the rust-lang/rust repo
infcx
.type_implements_trait(p.def_id, [ty.into()].into_iter().chain(p.substs.iter()), cx.param_env)
.must_apply_modulo_regions()
// vs
infcx
.type_implements_trait(p.def_id, iter::chain([ty.into()], p.substs.iter()), cx.param_env)
.must_apply_modulo_regions()
Some(t).into_iter().chain(slice::from_mut(u))
// vs
iter::chain([t], slice::from_mut(u)))
Solution sketches
// library/core/src/iter/adapters/chain.rs
pub fn chain<A, B>(a: A, b: B) -> Chain<A::IntoIter, B::IntoIter>
where
A: IntoIterator,
B: IntoIterator<Item = A::Item>,
{
Chain::new(a.into_iter(), b.into_iter())
}
pitaj, fmease, joseph-gio, tgross35, its-the-shrimp and 1 morejoseph-gio and GKFX
Metadata
Metadata
Assignees
Labels
ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)API Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries