(Also?) expose IpAddr in the API directly

[djahandarie]

Currently the API only accepts &strs, but that causes some ineffiencies in caller code if

1. you are already working with IpAddrs at the callsite, or
2. you want to process the results (which are IpAddr) and look up some things at the callsite which are key'd on IPs, at which point you'd need to convert the results back to strs, or convert the IP keys at the callsite to IpAddr, doubling the amount of work either way.

[bparli]

Hi @djahandarie - I take your point but a little leary of this one. At first glance, I'm not sure how to do it in an intuitive way that won't require a major API change. I'll think on it some more but also open to suggestions

[rcloran]

An example implementation that maintains API compatibility: https://gist.github.com/rcloran/1b252ddcc1a0ee2c4530b217639635b1

There are a few downsides to doing it this way:

• It seems that the compiler doesn't know how to find the right implementation with implicit types (https://gist.github.com/rcloran/abda671f0b3df02ddefa03d16e9e2196)
• AddrContainer leaks (see above example)
• Can't add deprecated annotations on trait impl (https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ab327b6f13991e176bf5d9b40222b4af)

Of course, simply adding a new fn add_addr(..., : IpAddr) (note no "ip") or some other name that makes sense would allow keeping the string version around but marked deprecated for a version.

I'd argue for breaking the API. I think it needs to break either as suggested in this issue or as in #34 . There are a couple of other places that I think would benefit from API changes, too.