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

@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 #-}

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 #-}

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.

@treeowl @eborden Thank you for your clarification.

Are we ready for merging?

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.

Rebased just in case.

Merged. Thank you for your review!