in #414 socklen_t and sa_family_t were changed to use types from windows-sys, which themselves were added to the win32metadata by request, in microsoft/win32metadata#1041 (both as NativeTypedefs). however, sa_family_t was later changed to MetadataTypedef in microsoft/win32metadata#1538 because it was an "invented" handle type (meaning it doesn't exist in any of the Windows SDK header files but only in win32metadata). socklen_t, on the other hand, does exists in the Windows SDK header "WS2tcpip.h", so it remains NativeTypedef.

it turns out that the equivalent to POSIX sa_family_t in Winsock2 is the ADDRESS_FAMILY type, and it existed forever. I think it's a mistake to request a win32metadata only typedef while ingoring the proper Windows SDK type,- and I'd suggest we change our sa_family_t to use the proper type, i.e. windows_sys::Win32::Networking::Winsock::ADDRESS_FAMILY, which also makes it consistent with other Winsock2 APIs, for instance, in windows-sys (and also windows), the type of SOCKADDR::sa_family and SOCKADDR_STORAGE::sa_family is ADDRESS_FAMILY, the constants AF_INET, AF_INET6 are defined using type ADDRESS_FAMILY, and some iphelper functions like GetIpForwardTable2() accept ADDRESS_FAMILY as argument.

btw, I discovered #414 when I was investigating the discrepancy of wrapper types from the windows crate. microsoft/windows-rs#2627