[GH-ISSUE #730] Lookup results should implement `IntoIterator` #283

New issue

Closed

opened 2026-03-07 23:16:00 +03:00 by kerem · 3 comments

kerem commented

2026-03-07 23:16:00 +03:00

Owner

Originally created by @olivia-fl on GitHub (Apr 5, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/730

I'm trying to return a mapped iterator over LookupIp from a function. This doesn't work right now without first collecting the LookupIpIter into a container, and then calling into_iter. This is because LookupIpIter borrows LookupIp, so you can't return it from a function since it borrows a local variable.

Ideally, all of the *Lookup* structs that have an iter method should also implement IntoIterator so that you can do this type of thing. It would behave identically to the current iterators, except that it would own the lookup struct rather than borrowing it.

Obviously, the .collect::<Vec<_>>().into_iter() approach does work, but it's both extra boilerplate and less efficient.

Originally created by @olivia-fl on GitHub (Apr 5, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/730 I'm trying to return a mapped iterator over `LookupIp` from a function. This doesn't work right now without first collecting the `LookupIpIter` into a container, and then calling `into_iter`. This is because `LookupIpIter` borrows `LookupIp`, so you can't return it from a function since it borrows a local variable. Ideally, all of the `*Lookup*` structs that have an `iter` method should also implement `IntoIterator` so that you can do this type of thing. It would behave identically to the current iterators, except that it would own the lookup struct rather than borrowing it. Obviously, the `.collect::<Vec<_>>().into_iter()` approach *does* work, but it's both extra boilerplate and less efficient.

kerem

2026-03-07 23:16:00 +03:00

closed this issue
added the
cleanup

crate:resolver
labels

kerem commented

2026-03-07 23:16:16 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 6, 2019):

This is a good suggestion. I’m happy to take pull requests. Otherwise I’ll play around with this when I have some time.

@bluejekyll commented on GitHub (Apr 6, 2019): This is a good suggestion. I’m happy to take pull requests. Otherwise I’ll play around with this when I have some time.

kerem commented

2026-03-07 23:16:21 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 7, 2019):

So looking at this, there's a bit of a complication, which is that ideally the interface would look like this:

impl IntoIterator for Lookup {
    type Item = RData;
    type Iterator = LookupIntoIter;

    fn into_iter(self) -> LookupIntoIter {
        unimplemented!()
    }
}

The issue is that the Lookup types wrap an Arc of the Vec of the returned records. This is because the records are cached and returned from the cache. What we can do is Arc::try_unwrap, but this will generally fail, and we'll end up cloning the internal Vec, thus being a costly conversion. As an ease of use thing, this is fine, but it's too bad that it will incur this cost.

@bluejekyll commented on GitHub (Apr 7, 2019): So looking at this, there's a bit of a complication, which is that ideally the interface would look like this: ```rust impl IntoIterator for Lookup { type Item = RData; type Iterator = LookupIntoIter; fn into_iter(self) -> LookupIntoIter { unimplemented!() } } ``` The issue is that the Lookup types wrap an `Arc` of the `Vec` of the returned records. This is because the records are cached and returned from the cache. What we can do is `Arc::try_unwrap`, but this will generally fail, and we'll end up cloning the internal `Vec`, thus being a costly conversion. As an ease of use thing, this is fine, but it's too bad that it will incur this cost.

kerem commented

2026-03-07 23:16:26 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 7, 2019):

Ok, @Benjamin-L, see #734 for my suggested implementation. Let me know if you had something else in mind.

@bluejekyll commented on GitHub (Apr 7, 2019): Ok, @Benjamin-L, see #734 for my suggested implementation. Let me know if you had something else in mind.

kerem referenced this issue

2026-03-16 02:01:04 +03:00

[PR #283] [MERGED] Update data-encoding major version #1340