是否可以将 `Keys<'_, K, V>` 迭代器作为 `&K` 的更通用的迭代器返回？

Question

I would to write a method that returns self.hash_map.keys() while hiding from the caller the concrete type Keys<'_, K, V> .

A downside of the Keys return type is that it exposes to the caller that the K elements are coming from a HashMap. Intuitively, it seems as though it shouldn't be necessary to expose this information.

• What is the cheapest way (with respect to CPU/allocations) to return an iterator of key references?
• Can it be accomplished by some precise choice of return type? Is some form of type-erasure possible?
• Or does it require an invocation in the function body? Is some transformation necessary?

Answer 1

Both of the options you speculated about are possible.

The simplest option is to use the impl type syntax, which is an “existential” type: “I am going to return a value which implements Iterator but I'm not telling you what the concrete type is”. In this case, the compiler knows what the type is (so the compiled code is exactly the same as if it wasn't hidden), but the user of your method cannot rely on anything but the specified trait, so you aren't leaking implementation details.

impl MyType {
    fn keys(&self) -> impl Iterator<Item = &MyKeyType> {
        self.hash_map.keys()
    }
}

(Note that this resembles but is not the same as dyn Iterator ; when you use dyn , you're using runtime dispatch and the same function can return different concrete types from different calls to it. With impl , the type is static, just hidden, and there is no overhead.)

The disadvantage of this option is that the type is entirely unnameable; for example, nobody can write a structure that holds your keys() iterator except by making it generic over all Iterator s. (This is rarely a problem for iterators in particular, since iterator wrappers are usually generic anyway.)

Also, if your iterator implements any additional traits you want to allow the caller to use, like Debug or ExactSizeIterator , then you need to add them to the impl type or they won't be visible.

---

Another option is to wrap the iterator in your own struct. This allows you to hide the implementation type while still allowing callers to refer to it by name, so it's the most flexible. The disadvantage of this option is that you have to explicitly implement Iterator (and any other traits) for the wrapper:

impl MyType {
    fn keys(&self) -> MyKeyIterator<'_> {
        MyKeyIterator(self.hash_map.keys())
    }
}

#[derive(Clone, Debug)]
struct MyKeyIterator<'a>(Keys<'a, MyKeyType, MyValueType>);

impl<'a> Iterator for MyKeyIterator<'a> {
    type Item = &'a MyKeyType;

    fn next(&mut self) -> Option<&'a MyKeyType> {
        self.0.next()
    }
}

Rust Playground link with supporting code

This wrapper should not add any performance cost (when compiled with optimization), except that by default the wrapper method will not be inlined if called from another crate. If you're writing a library and this method is performance-sensitive, you can either enable link-time optimization (LTO) in the build, or add #[inline] to the next method (which enables cross-crate inlining). Of course, don't do any such tweaking without checking whether it makes a difference to actual performance; otherwise you're just increasing compile time (and instruction cache thrashing).

Answer 2

Can it be accomplished by some precise choice of return type? Is some form of type-erasure possible?

Yes! You can return an impl Trait to indicate that you're returning a type that implements Trait but doesn't expose the concrete type:

fn keys(&self) -> impl Iterator<Item = &K> {
    self.hash_map.keys()
}

See it working on the playground .