Bug 4234 – Cannot create a std.socket.Socket from an fd

I have a socket fd that is set up for communicating with my parent process, and I need to talk to it. Socket.sock is declared private, and there's no way to access it. Maybe just make it protected or something?

I had exactly the same problem, see http://www.digitalmars.com/d/archives/digitalmars/D/std.socket_is_horrible._115977.html The easiest way to fix this (as proposed by Christopher E. Miller, the original author of std.socket), is to just add a constructor that takes a socket_t and a AddressFamily: this(socket_t sock, AddressFamily af) { assert(sock != socket_t.init); this.sock = sock; this._family = af; } A related issue however is it's impossible to derive from std.socket.Socket and overwrite methods that take an std.socket.Address - because the most important methods of Address (name() and nameLen()) are private and thus can't be accessed outside of std.Socket. This was discussed in aforementioned NG thread as well and the solution is: * make these methods (Address.name() and Address.nameLen()) public * Socket.newFamilyObject() is private, but should be protected so you can derive std.Socket to get a Socket that supports new Address types (e.g. local Addresses) (That issue is related because it makes it *really* hard to just derive from std.socket.Socket and overwrite everything and add a constructor that takes a socket_t. But there are of course other scenarios for deriving from Socket that are still valid when this bug is fixed.)

A solution for this issue has already been proposed, but up until now there seems to have been no changes. I can try to make a patch if that's all what's stopping it to be solved.

This seems to be covered by Chris's update in Issue 5401. > * Socket.newFamilyObject() is private, but should be protected so you can > derive std.Socket to get a Socket that supports new Address types (e.g. local > Addresses) newFamilyObject is still private, but it calls createAddress() which is protected. *** This issue has been marked as a duplicate of issue 5401 ***