Skip to content
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

Refactoring ProtocolNumber as newtype #468

Open
archaephyrryx opened this issue Jul 16, 2020 · 1 comment
Open

Refactoring ProtocolNumber as newtype #468

archaephyrryx opened this issue Jul 16, 2020 · 1 comment

Comments

@archaephyrryx
Copy link
Contributor

In the current implementation of network, the ProtocolNumber type, defined in Network.Socket.Types, is given as

type ProtocolNumber = CInt

which means that it can only ever be displayed using the show method for Foreign.C.Types.CInt.

I initially was considering working on redefining it along the lines of

newtype ProtocolNumber = ProtocolNumber CInt
    deriving (Eq, Ord, Enum, Real, Num, Integral)

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.

@kazu-yamamoto
Copy link
Collaborator

I encourage you to continue this work. Your work would be merged into the next major release (probably soon) because of compatibility issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants