Un-deprecate IpAddr

[canndrew]

The IpAddr type recently got deprecated from the standard library.

This means libstd now has:

• A type for (ipv4 address, port) pairs: SocketAddrV4
• A type for (ipv6 address, port) pairs: SocketAddrV6
• A type for (ip address, port) pairs: SocketAddr
• A type for ipv4 addresses: Ipv4Addr
• A type for ipv6 addresses: Ipv6Addr
• But not a type for ip addresses: IpAddr

This is silly. IpAddr fits in perfectly with the other types here. It's useful to be able to decompose a SocketAddr into IpAddr and port components and to build one out of these components. It we're going to remove IpAddr then shouldn't SocketAddr be removed aswell? It's very odd to not have a type for generic IP addresses but to have one for generic IP address + port.

There's also at least one place in the standard library itself where IpAddr is needed. The lookup_host function returns an iterator of SocketAddrs with a dummy port because it doesn't have IP address type to use.

The deprecation notice describes IpAddr as being "too small to pull it's weight". Isn't being small a good thing? A type that only takes up a few lines of code doesn't come with much maintainance burden. Surely it's large, complicated types that implement specialised functionality that deserve to be spun off into their own libraries?

Can we just put IpAddr back?

[tshepang]

"too small to pull it's weight" looks like it means "not enough functionality to deserve a place in std"

[vinipsmaker]

"too small to pull it's weight" looks like it means "not enough functionality to deserve a place in std"

This little feature saves a lot of typing. I'm just having to repeat myself every time I need this little feature.

[canndrew]

Just being the Item of LookupHost should be enough functionality.

[tshepang]

LookupHost is not even stable

[sfackler]

We want to move DNS lookup out of tree and deprecate the in-tree functionality so the API can be improved: rust-lang/rust#27705.

[arcnmx]

+1 this is a very useful type to have a common definition of, and fits in with the rest of std's net types. The ip crate works but really shouldn't be necessary, even if the type isn't used much as an input by std::net APIs themselves.

[dimbleby]

+1

It certainly makes no sense to have SocketAddr but not IpAddr. That's not intended to encourage deprecation of SocketAddr: I'd much rather have IpAddr back.

[dirvine]

+1 for IpAddr being returned. The workarounds are possible with ip crate or own copy etc. but ends up with very messy files and code that is more confusing than it needs to be. This seems to be well used by many projects and seems everyone is working around something in almost the same way. So makes sense to have this in std, esp if socketaddr is, which is really helpful.

[SimonSapin]

@sfackler “DNS lookup” includes the de-facto-stable implementations of ToSocketAddrs for (&'a str, u16) and str. (Only they attempt to parse an IP address before asking libc/the system to resolve a name.) Are they moving out of tree too?

@alexcrichton I remember discussing with you criteria for what should be in std or not. Is that written down somewhere? One of them is when the ecosystem benefits from everyone using the same “standardized” types or traits, allowing interoperability between libraries that don’t depend on each other. I std::net exists at all, I think IpAddr qualifies.

+1

[ustulation]

+1

[sfackler]

@SimonSapin Those trait implementations can't move, so no, they're staying where they are.

[wenLiangcan]

+1

[dimbleby]

I had an issue report the other day pointing out another reason that the ip crate is not a fully satisfactory replacement: it's not possible for a crate to implement ToSocketAddrs on the (ip::IpAddr, u16) pair.

Not the worst thing in the world, for sure, but for whatever it is worth this speaks in favour of reinstating std::net::IpAddr.

[jfager]

Haven't we already gone through this dance? #988 It's a tiny unifying enum for a bog-standard use case that multiple people on multiple occasions have said they use and will need to reimplement if it disappears. Please just keep it.

[alexcrichton]

The libs team discussed this at triage today, and the conclusion was that given how much support there is for this type that we can likely just change the deprecated tags to stable. The type has already gone through an FCP and is a pretty minor surface area, so there's not necessarily any need for another FCP.

[aturon]

Yep, it was clearly the wrong decision to deprecate -- there's a clear community consensus to ship this, and the rationale for deprecation essentially boiled down to a concern about minimalism in std; there's no real maintenance burden here.

In any case, I've opened a PR to revert, which actually stabilizes the enum as of 1.7 (currently in beta). That will require a backport.