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
so that the implicit constraint Num a => a on numeric literals would be maintained, and so that it would be possible to define custom Read/Show instances that used pattern synonyms for commonly used protocols (e.g. TCP and UDP) for human-readability. (Along the lines of the pattern-synonym read/show work I implemented in #465 and #466)
Values that correspond to obsolete or extremely uncommon protocols could just be represented numerically, without any constructor syntax, as they are currently represented (and parsed) by default.
However, @vdukhovni pointed out that this would break the API for anyone using either variables or literals with explicit :: CInt signatures where ProtocolNumber values are expected, which could be either a trivial issue or a major problem depending on how common such usage is in the countless projects that have a dependency on network.
In any case, it seemed like enough of an obstacle that I wanted to consult with the project maintainers before I embark on a doomed mission that would break an indeterminate fraction of network-dependent code.
The text was updated successfully, but these errors were encountered:
In the current implementation of network, the
ProtocolNumber
type, defined inNetwork.Socket.Types
, is given aswhich means that it can only ever be displayed using the
show
method forForeign.C.Types.CInt
.I initially was considering working on redefining it along the lines of
so that the implicit constraint
Num a => a
on numeric literals would be maintained, and so that it would be possible to define custom Read/Show instances that used pattern synonyms for commonly used protocols (e.g. TCP and UDP) for human-readability. (Along the lines of the pattern-synonym read/show work I implemented in #465 and #466)Values that correspond to obsolete or extremely uncommon protocols could just be represented numerically, without any constructor syntax, as they are currently represented (and parsed) by default.
However, @vdukhovni pointed out that this would break the API for anyone using either variables or literals with explicit
:: CInt
signatures whereProtocolNumber
values are expected, which could be either a trivial issue or a major problem depending on how common such usage is in the countless projects that have a dependency on network.In any case, it seemed like enough of an obstacle that I wanted to consult with the project maintainers before I embark on a doomed mission that would break an indeterminate fraction of network-dependent code.
The text was updated successfully, but these errors were encountered: