Refactor windows sockets impl methods

[mjptree]

No behavioural changes, but a bit tidier visual flow.

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

I'm not an expert on the Windows sockets API. @rustbot ping windows

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra @wesleywiser

[JohnTitor]

Indeed this shouldn't have any semantic changes and I agree there're some improvements e.g. using map(drop), extracting some code that is unnecessary to be in match. But on the other hand, I'm not sure if some other changes are improvements, e.g. renaming (I think it's obvious that what len or fam means in the short scope, for instance), binding, shuffling match arms. Could you elaborate?

[mjptree]

@JohnTitor The renamed variables were a suggestions to use full names instead of abbreviations, but I agree they may not be improvements. The shuffling of match arms had multilple motivations: a) avoid calling GetLastError multiple times to retrieve the same error code (e.g. Socket::recv_with_flags), b) unnest nested matches (e.g. Socket::new), and c) clarify cases in which match cause divergent control flow (e.g. Socket::connect_timeout). The binding was in almost all cases aimed at reducing the scope of unsafe blocks to the invocation of the C function alone. I found it particularly helpful to recognize, that some blocks encompassed multiple unsafe invocations in single block alongside "safe" code.

[JohnTitor]

That makes sense, thanks for clarifying! Then I think it's good to go.

[JohnTitor]

@bors r+ rollup

[bors]

📌 Commit 78d3d37 has been approved by JohnTitor