UnixStream type available as dummy API on Windows, so using this type on Windows will be runtime error on Windows instead of compile-type error on Windows.
I have a couple of libraries I maintain.
These libraries work on Windows, more or less. I do not test them explicitly (I don't have an access to Windows machine and configuring Windows CI for a small project is painful), but since TCP sockets work similarly on all OS, these libraries work on Windows too.
On Unix (Linux, macOS) these libraries also support Unix sockets. Unix sockets do not work on Windows, and that's fine.
However, I often encounter a problem, when I break compilation of my libraries on Windows simply because I have to guard all Unix/non-Unix specific code with
I change for example unix-specific function signature and forget to change windows-specific signature (and if I correctly change Windows-specific signature, I don't know how I could test it).
So my proposal.
UnixSocket type available on Windows (and all other environments).
bind operations would return
io::Error "not supported".
So all library code will be typechecked for operating systems in single
cargo check run.
And people can continue using
cfg(not(unix)) if they wish to hide some functions from their projects in specific environment.
What others do
Some other projects do it. For example, Java many years resisted introducing OS-specific functions into the JDK, but now Java provides basic access to OS-specific API. The example is, now in Java it is possible to read POSIX file attributes (like owner and group).
Function getFileAttributeView accepts
PosixFileAttributeView object (which is available on all operating systems), but returns
null if POSIX file attributes are not supported.
Node.js and libuv
Node.js and libuv actually implement unix-socket-like API on Windows using pipes (so the path-socket code actually works across different operating systems except that paths on Windows must be not filesystem paths, but something like
Edit: typo in type name