Tracking Issue for Iterator::join

[pickfire]

This tracking issue is to create a more ergonomic method to join on Iterator 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

["hello", "world"].iter().collect::<Vec<_>>().join(" ")

After

["hello", "world"].iter().join(" ")

It makes use of Join under slice_concat_trait feature #27747 and have a similar behavior to Iterator::collect.
It is similar to join from itertools except that it makes use of the stuff mentioned for feature parity between Iterator and join and ergonomics to not need to do .collect::<Vec<_>>().

Technical implementation proof of concept.

pub fn join<T, Separator>(iter: impl Iterator<Item = T>, sep: Separator) -> <[T] as Join<Separator>>::Output
where
    [T]: Join<Separator>,
{
    // <[S] as std::slice::Join<&str>>
    // <[V] as std::slice::Join<&T>>
    // <[V] as std::slice::Join<&[T]>>
    Join::join(iter.collect::<Vec<T>>().as_slice(), sep)
}

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

• Implement the RFC (cc @rust-lang/T-libs @Amanieu @cuviper) - Add Iterator::join to combine Iterator and Join #75738
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Figure out potential performance improvements CC @lzutao
• Add clippy lint to use .join(sep) rather than .collect::<Vec<_>>().join() after stabilization? Is it even possible when it goes across lines?

Implementation history

• Initial Implementation: WIP (please let me do this)

[leonardo-m]

Very good. After this, a basic feature that's still missing in Rust stdlib is to be able to print the items of a lazy iterable (with no vec conversions first), useful for debugging, etc. (This feature is already available in Itertools).

[pickfire]

Very good. After this, a basic feature that's still missing in Rust stdlib is to be able to print the items of a lazy iterable (with no vec conversions first), useful for debugging, etc. (This feature is already available in Itertools).

That is not quite true, I still have yet figured out a way to do that without doing a vec conversion first. If you don't do a vec conversion, you need to allocate N times the iterator length + N - 1 times for the separator. But if you do the conversion first, you only need to allocate once for the vec and once for the converted size, I think it probably could be done but I haven't figure it out yet. Hopefully, there is a way to only allocate once and iterator the iterator once.

[joshtriplett]

It looks like the corresponding PR was closed, so closing this tracking issue.