Because they were implemented in a rather recent version of Windows 10.

meanwhile I created a crate for it https://crates.io/crates/uds_windows

Is the argument here
"only a recent version of win10 supports it, so it doesn't belong in STD"
or
"only a recent version of windows 10 supports it, so nobody has added support yet?"

Definitely the former because std supports Windows 7 as a tier 1 platform. Considering you can use a third party crate for unix domain sockets on windows as is, there is very little reason to put them in std.

I'd love to see this feature make it's way eventually. Cross-linking a conversation on internals for discoverability.

As an FYI: I am working on a pre-RFC for min_target_api_version which allows for conditional compilation based on the minimum support API version for the target platform. This could address the issue that this would not be supported on older versions of Windows. With this mechanism, Unix sockets would only be available when compiling for a min_target_api_version that supports Unix sockets. Though this would likely only benefit those who build their own version of the standard library.

Hello from 2022 👋 Just wanted to provide some updated info here

Windows 10 version 1803, the version introducing UDS, is now over four years old. This and all earlier Windows 10 version has reached end of mainstream service already.

Windows 10 1803 is older than:

• Debian 10 - The oldest Debian release that is not EOL (will go EOL any week now?)
• Ubuntu 18.04 - The oldest Ubuntu release that is not EOL (less than a year left)
• macOS 10.14 - EOL since 2021

this is silly. imo the std's code should have support for both either through different code or with an wrapper api.
if the user pics UDS while targeting w7 its on them imo.

Hello from 2023 👋, Any progress on this?

What is blocking this from happening?
Is the stance still that Windows 7 does not support this so it won't happen?
At what point will Windows 7 no longer be a Tier 1 platform?
Even the extended security updates have now ended
And why does it even matter?
Is it to have consistency between operating systems
Even though there are already features, such as ironically Unix Domain Sockets, that only work on certain operating systems.

I know that a third party library allows them to be used.
However it becomes an extra hurdle for UDS adoption on windows.
As can be seen in the mentions, there are crates that only support Linux because of this issue.
For example, I personally wanted to use them for a Deno project but found out that UDS is stuck in unstable due to this issue.
Which is a shame in my opinion...

Prefixing this with "not a Rust project member" but now that Windows 7 and 8 have had their end-of-support defined for Rust in rust-lang/compiler-team#651, sometime early 2024 seems like it would be a uncontroversial time to start an implementation of UDS for Windows backends because the stdlib can assume only 10 will run its code.

If anyone would like to make progress on this issue then a way forward would be to make an API Change Proposal (ACP) that details the proposed API. If accepted, it would then of course need someone to implement it.

libuv/libuv#2537 (comment)

no need to bother with unix domain socket on windows

The Windows implementation of AF_UNIX does not support abstract sockets. The bug is the lack of documentation on what is supported and that the announcement blog post includes misleading information. Filesystem based UDS works.

Golang implements AF_UNIX on Windows, maybe it can be a reference

The issue is not the implementation (which is simple enough). The problem is the API design. Somebody likely needs to create an API Change Proposal that sketches the design and notes the issues. There's already one, in fact. rust-lang/libs-team#271

Update: The API Change Proposal was just accepted. So now we do just need the implementation.