Deprecate std::net?

#1

There is an std::net wishlist about things like letting you set separate local IPs for separate users among other things, but it hasn't gone anywhere in 5 years. Would be nice to just deprecate std::net instead.

At least BSD sockets are a fairly standard API across all OSes so there's not much to be lost here...

#2

If I'm understanding you correctly, you want to deprecate the entire (widely-used) module because something from your "wishlist" hasn't been added? What's the justification for that?

9 Likes
#3

The API is unnecessarily restrictive. It only works for the most basic of use-cases and programs using it instead of other libraries are missing out.

#4

Speaking as a library team member, I don't see this happening. And I don't think it's terribly productive to open a discussion like this with just a couple sentences. If you want to claim that the API is unnecessarily restrictive and only works for basic use cases and that folks are somehow missing out by using it, then please don't just say, show it with examples. And after you show it, you should be providing some kind of analysis that motivates and explains why deprecation would fix it and what the drawbacks of such an action would be.

27 Likes
#5

Ok? I'd be willing to bet that those libraries depend on stdlib. What purpose does deprecation serve? If it's unnecessarily restrictive, contribute. Saying "I don't like this, so no one else should have it either" is about as unproductive as it gets.

#6
  • ZNC allows ZNC hosts to use one IP address per ZNC user. Quassel uses Qt networking and Qt networking doesn't expose said functionality. Rust, like Qt, doesn't expose said functionality. Quassel users recently requested said functionality but had to be told no because of unnecessarily restrictive APIs.
  • set_only_v6 in TcpListener is deprecated. It doesn't work, and can't be made to work. And yet it was desirable or else it wouldn't have been added in the first place. Ouch.

The current API design is incompatible with all of these. We think it needs to be re-engineered from scratch. We think that would be the best way to go about it. Networking is highly desirable, and it should definitely be in the standard library, just... maybe not in its current form.

#7

Note that there is the net2 crate which probably does most or all of what you're after. Supposedly, the stuff in net2 is slated for inclusion in the standard library, though there doesn't seem to have been any progress on that front since forever.

#8

net2 has itself been deprecated in favor of socket2.

3 Likes
#9

As a user thereof, I would find it very surprising for all of std::net to suddenly be deprecated, especially before a replacement has been stabilized.

It seems like if std::net isn't meeting your needs you should be using socket2. Perhaps if that were ever included into std the current std::net APIs could be deprecated, but I don't think it makes any sense to do that until a stable replacement is in-place.

8 Likes
#10

The title of the topic seems scary, but I think it touched upon an important question.

I worked on a project in Rust that needs network programming. I found that Rust has multiple options for socket programming, but each with its own problems (in my view):

  1. std::net - does not support low-level socket APIs, for example setsocketopt.
  2. crate socket2 - does not have related APIs, for example get all local interface IP addresses.
  3. crate nix - does not provide a Rust socket abstraction, using RawFd instead.

And because there are 3 of them, the mixing of their definitions (symbol names) also cause confusions.

(There is also separate async socket implementation I didn't get into).

I asked the above question sometime ago on Reddit and eventually went with using crate nix only. But I was wondering, what's the plan for the std::net? Any plan to merge socket2 or some of nix into it, or something else?

4 Likes