-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does getAddrInfo return IO (NonEmpty AddrInfo)? #407
Comments
I think it's too late to change the result type to |
Ah, that's a shame. I personally disagree, but you have a lot of reverse-dependencies to consider. Here is a PR to raise an exception. |
I don't understand why you think it's a shame. |
Correct, we will have to throw some exception (even if it is just an I believe that types should convey as much information as practically possible. The implied contract of functions in this library is "result or throw exception", which means that for But as you said earlier, it might be too late to change that type because it breaks so many reverse dependencies. I might make changes to the example code on my PR branch, so that people get in the habit of immediately turn the |
@endgame The more compatible way to change the type of |
I am willing to prepare such a PR. My initial thought was
What did you have in mind? |
Ah, I forgot. The other problem with bringing in |
Yes, the dependency issues is a problem. Our official support is 3 versions, so technically we are really only bound to For now the exception proposal gets us visibility if an issue occurs. |
I was a fan of In the case of We would feel very good if we provided good type signatures for APIs. But it is inconvenient for uses to ask change the current style and switch to |
Since GHC 9.8 or later warn partial functions, I begin to think to provide: getAddrInfoNE
:: Maybe AddrInfo
-> Maybe HostName
-> Maybe ServiceName
-> IO (NonEmpty AddrInfo) |
See #587. |
The documentation for
Network.Socket.getAddrInfo
specifies that:That the
res
pointer is given a non-empty list appears to be required by POSIX:The manpages on my system do not mention this postcondition.
The implementation in
Info.hsc
does not seem to enforce this.How best to proceed? The ideal world in my mind involves returning
IO (NonEmpty AddrInfo)
, but there are some complications:base >= 4.9
(GHC >= 8) gives usNonEmpty
.semigroups
for GHC < 8.semigroups
' dependencies are boot packages, but not all; I do not know whether this is acceptable.Whether or not
getAddrInfo
returnsNonEmpty
or[]
, should we guarantee that a nonempty list is returned by throwing, if we see an empty list inres
? The function is already potentially throwingIOError
.The text was updated successfully, but these errors were encountered: