You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed somewhat in #1907, SocketAddress is a fairly painful type with a very awkward API surface. It has a prominent place in the API, one that is very difficult to reconcile with the way modern networks function (see #508). That prominent place also interacts awkwardly with that reality, as SocketAddress prominently uses the sockaddr_* types and is wedded to the decisions those types make.
There are a number of ways this could be made better in a future version:
The distinction between address families does not need to be part of the API of this type, and you certainly don't need to be able to produce a wrapper for SOCK_STREAM from this. We should let NIOBSDSocket be responsible for managing that, not us.
The text was updated successfully, but these errors were encountered:
As discussed somewhat in #1907,
SocketAddress
is a fairly painful type with a very awkward API surface. It has a prominent place in the API, one that is very difficult to reconcile with the way modern networks function (see #508). That prominent place also interacts awkwardly with that reality, asSocketAddress
prominently uses thesockaddr_*
types and is wedded to the decisions those types make.There are a number of ways this could be made better in a future version:
Stop storing things in C types.
While NIO requires that we be able to produce C types, we don't need to store things there! This would let us improve the layout of the type, and take advantage of any work done as part of Provide IPAddress type #1650. This would also address C system types are exposed, which may be incompatible #1673.
Stop exposing C flags for address family.
The distinction between address families does not need to be part of the API of this type, and you certainly don't need to be able to produce a wrapper for
SOCK_STREAM
from this. We should letNIOBSDSocket
be responsible for managing that, not us.The text was updated successfully, but these errors were encountered: