Tracking Issue for Iterator::join #75638
Labels
A-iterators
Area: Iterators
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
Libs-Tracked
Libs issues that are tracked on the team's project board.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
This tracking issue is to create a more ergonomic method to
join
onIterator
without collect. Hopefully, we can do some optimizations on top of it but I haven't think of any case to improve it.The feature gate for the issue is
#![feature(iterator_join)]
.Before
After
It makes use of
Join
underslice_concat_trait
feature #27747 and have a similar behavior toIterator::collect
.It is similar to
join
fromitertools
except that it makes use of the stuff mentioned for feature parity betweenIterator
andjoin
and ergonomics to not need to do.collect::<Vec<_>>()
.Technical implementation proof of concept.
Existing discussion on zulip https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/join.20on.20Iterator
Related issue #22754
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
.join(sep)
rather than.collect::<Vec<_>>().join()
after stabilization? Is it even possible when it goes across lines?Implementation history
The text was updated successfully, but these errors were encountered: