Tracking Issue for Iterator::{dedup, dedup_by, dedup_by_key}

[slerpyyy]

Feature gate: #![feature(iter_dedup)]

This is a tracking issue for the functions std::iter::Iterator::{dedup, dedup_by, dedup_by_key} as well as the structs std::iter::{Dedup, ByKey, ByPartialEq}.

This feature provides similar functionality as the functions for slices and Vecs with the same name:

let vec = vec![1, 2, 2, 3, 2];

let mut iter = vec.into_iter().dedup();

assert_eq!(iter.next(), Some(1));
assert_eq!(iter.next(), Some(2));
assert_eq!(iter.next(), Some(3));
assert_eq!(iter.next(), Some(2));
assert_eq!(iter.next(), None);

Public API

pub trait Iterator {
    /// Removes all but the first of consecutive elements in the iterator
    /// according to the `PartialEq` trait implementation.
    fn dedup(self) -> Dedup<Self, ByPartialEq>
    where
        Self: Sized,
        Self::Item: PartialEq,
    { ... }
    
    /// Removes all but the first of consecutive elements in the iterator
    /// satisfying a given equality relation.
    fn dedup_by<F>(self, same_bucket: F) -> Dedup<Self, F>
    where
        Self: Sized,
        F: FnMut(&Self::Item, &Self::Item) -> bool,
    { ... }
    
    /// Removes all but the first of consecutive elements in the iterator
    /// that resolve to the same key.
    fn dedup_by_key<F, K>(self, key: F) -> Dedup<Self, ByKey<F>>
    where
        Self: Sized,
        F: FnMut(&Self::Item) -> K,
        K: PartialEq,
    { ... }
}

Steps / History

• Implementation: Add dedup, dedup_by and dedup_by_key to the Iterator trait #83748
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Is there a way to reduce dedup and dedup_by_key to a call to dedup_by without creating an impossible function signature?
• Should we also implement SourceIter and InPlaceIterable for these structs?
• How should/can we react to an infinite iterator where all items are the same?
• Is there a way to turn this into a no-op for iterators which cannot contain duplicates (e.g. hashset.iter().dedup())?

[leonardo-m]

This is probably going to be rather useful.

[shhra]

This should be handy when designing language processing algorithms.