I had thought about the only provide
CInt interface. I personally think that this isn't too terrible, although I do wonder about the cost in the sense that it beaks a lot of often cited examples. It would break a lot of compatibility with existing snippets, although admittedly those snippets would be C and not Swift code. Perhaps that cost is not too high, but at the same time, the ability to quickly go from MSDN snippets to working code has been extremely helpful and convenient. I think that APINotes would be the more preferable route here.
I do like the preference trick, but, I think that the more interesting case here is to consider if we want to actually change the API behaviour in these cases (aka, your third point). This approach is really the one that I least like.
Returning an enumerated type is one option. I think that given how Swift handles errors, I would actually prefer that the function signature remain as is, but the function becomes throwing. This was the approach I wanted to play with further over what I ended up with. The problem here is really that there is no mapping from the windows error to
Error. There is some prior work related to this in NIO which has a custom Error type that allows conversion from Windows Error and errno errors and tracks provenance as well. This really maps well to the construct as the type is being used:
FALSE) on error.
func GetMessageW(_ lpMsg: LPMSG?, hWnd: HWND?, _ wMsgFilterMin: UINT, _ wMsgFilterMax: UINT) -> Bool throws
This feels the most Swift inspired way to treat the function - and remains the most clear at the site of use. Mapping the Windows error to
Error is really the piece that would make this work really well IMO.
I think the point of which is best is really the problem that I have with this too. I couldn't readily convince myself that any one way is strictly better but rather there are differing tradeoffs with the designs. This prevented me from trying to add this immediately to the WinSDK overlay.