defining CustomSockOpt again with ViewPatterns.

[kazu-yamamoto]

As David Feuer suggested in haskell-cafe, the CustomSockOpt pattern can be defined with ViewPatterns.

Relating to #414.

[kazu-yamamoto]

If we want, we can make CustomSockOpt deprecated suggesting getSockOpt and setSockOpt.

[treeowl]

Don't forget the COMPLETE pragma in case someone decides to use -Wincomplete-patterns.

[kazu-yamamoto]

@treeowl Do you suggest the following?

{-# COMPLETE Debug,ReuseAddr,Type,SoError,DontRoute,Broadcast
            ,SendBuffer,RecvBuffer,KeepAlive,OOBInline,TimeToLive
            ,MaxSegment,NoDelay,Cork,Linger,ReusePort
            ,RecvLowWater,SendLowWater,RecvTimeOut,SendTimeOut
            ,UseLoopBack,UserTimeout,IPv6Only
            ,RecvIPv4TTL,RecvIPv4TOS,RecvIPv4PktInfo
            ,RecvIPv6HopLimit,RecvIPv6TClass,RecvIPv6PktInfo
            ,CustomSockOpt #-}

[treeowl]

CustomSockOpt is complete all by itself, right? If so, it gets its own pragma. It seems unlikely any of those others combine to form a complete set, but I'm no expert. I would imagine

{-# COMPLETE CustomSockOpt #-}

[eborden]

Good call on COMPLETE. That is necessary to maintain a backwards compatible interface. CustomSockOpt does represent an otherwise case, so it is complete on its own. I also agree that the other patterns do not represent a complete set, since SocketOption is now open to extension.

[kazu-yamamoto]

@treeowl @eborden Thank you for your clarification.

Are we ready for merging?

[treeowl]

The pattern synonym looks fine. Can't comment on how it all fits with the rest of the library, because I'm not familiar with that.

[kazu-yamamoto]

Rebased just in case.

[kazu-yamamoto]

Merged. Thank you for your review!