Rewrite of std.socket for phobos.net.socket

[ichordev]

I'm working on a module that functionally replaces std.socket and I was wondering if I should adapt this into being the new phobos.net.socket module. It is still a wrapper of the Berkley socket API, but with different design goals:

• Minimal allocations: replace classes with structs; resource management is done via reference counting, similar to std.stdio.File.
• Use sumtypes instead of class inheritance. Currently this uses std.sumtype, but could be updated once real sumtypes are added to the language.
• Errors are handled by returning a Nullable (can be replaced with whatever phobos ends up having), or a sumtype where more than one type of failure is possible.
• Enforce correct API usage. For instance, no using TCP-only functionality on UDP sockets, since this usually causes platform-specific undefined behaviour.
• Better names that actually follow The D Style (no ALLCAPS, Udp, etc.), including for function parameters since they are part of the API now. (no so, af, or addr)

Any thoughts?
Also what would I do in the meantime while PhobosV3 doesn't have equivalents of Nullable, SumType, etc? Do I just use the V2 equivalents or would I have to wait forever?

[atilaneves]

We've been wanting more modern sockets in Phobos for a while now, so this would be nice.

[ichordev]

Excellent! Any particular features or improvements you'd like to see?

[jmdavis]

LOL. I've been working on a socket solution off an on for ages, but other stuff has taken priority (like the core Phobos v3 stuff). I don't know what we'll actually end up doing for sockets and Phobos v3, but it certainly doesn't hurt to have options.

Also what would I do in the meantime while PhobosV3 doesn't have equivalents of Nullable, SumType, etc? Do I just use the V2 equivalents or would I have to wait forever?

The core Phobos v3 stuff is not far enough along to build something like sockets on top of yet. For instance, I need to finish the range stuff before most other stuff can be done, and we'll need the UTF stuff and format stuff (both of which also depend on the range stuff) to do much of anything with strings. If you want to create a socket solution, I suggest that you create a library built on top of Phobos v2 and put it on code.dlang.org so that you can get something done without relying on Phobos v3 being far enough along to really be ready for sockets. It will also potentially give you a chance to get feedback from users before any socket stuff goes into Phobos v3, which could lead to a better design.

Once more of the core stuff is in place, we can look at stuff like sockets and containers and whatnot and figure out what we actually want to put for those in Phobos v3, and if we decide that we want some form of what you've been working on, then it can be ported to Phobos v3.

[denizzzka]

Please in the new Socket implementation provide ability to acquire and then not destroy foreign (Berkley) socket after destruction

For now, if you call:

auto s = new Socket(posixSocket, AddressFamily.UNSPEC);

then destroy s posixSocket will be closed.

It is very important to be able to not destroy acquired socket because this is a very common case of interaction with C libraries. As a result, we have to use ugly socket duplicating code like this for each time when we need to wait for event, etc.