ANN: network 2.8.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ANN: network 2.8.0.0

evan@evan-borden.com
Announcing the release of network 2.8.0.0
http://hackage.haskell.org/package/network-2.8.0.0

Version 2.8.0.0

* Breaking change: PortNumber originally contained Word32 in network
  byte order and used "deriving Ord". This results in strange behavior
  on the Ord instance. Now PortNumber holds Word32 in host byte order.
* Breaking change: stopping the export of the PortNum constructor in
  PortNumber.
* Use bytestring == 0.10.* only.
* Use base >= 4.7 && < 5.

--
Evan Borden

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: ANN: network 2.8.0.0

Viktor Dukhovni


> On Sep 4, 2018, at 6:22 PM, [hidden email] <[hidden email]> wrote:
>
> * Breaking change: PortNumber originally contained Word32 in network
>   byte order and used "deriving Ord". This results in strange behavior
>   on the Ord instance. Now PortNumber holds Word32 in host byte order.
>   [#347](https://github.com/haskell/network/pull/347)
> * Breaking change: stopping the export of the PortNum constructor in
>   PortNumber.

Small correction, the port number of course was and remains Word16 not Word32.

One might also note that to the extent that applications did use the
PortNumber in SockAddrInet, and SockAddrInet6 structures, they likely
relied on the Num, Enum and Integral instances, rather than using
"PortNum" directly.

Those instances made it possible to use numeric literals or "fromIntegral"
to create "PortNumber" from port numbers.  And this has not changed.  The
only thing that's no longer possible is direct use of the "PortNum" constructor
with values already in network byte order.  This should be a rare impediment,
and the removal of the constructor means that all problems are detected at
compile-time.

So this is unlikely to be an issue for the majority of applications, which
likely just use getaddrinfo() in any case, and don't build SockAddrInet*
structures "by hand".

--
        Viktor.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: ANN: network 2.8.0.0

Kazu Yamamoto (山本和彦)
Hi Viktor,

> Small correction, the port number of course was and remains Word16
> not Word32.

Right. This is my fault. I have fixed this typo in github.

> One might also note that to the extent that applications did use the
> PortNumber in SockAddrInet, and SockAddrInet6 structures, they likely
> relied on the Num, Enum and Integral instances, rather than using
> "PortNum" directly.
>
> Those instances made it possible to use numeric literals or "fromIntegral"
> to create "PortNumber" from port numbers.  And this has not changed.  The
> only thing that's no longer possible is direct use of the "PortNum" constructor
> with values already in network byte order.  This should be a rare impediment,
> and the removal of the constructor means that all problems are detected at
> compile-time.
>
> So this is unlikely to be an issue for the majority of applications, which
> likely just use getaddrinfo() in any case, and don't build SockAddrInet*
> structures "by hand".

Thank you for your explanation!
This is exactly what we the maintainers intend.

--Kazu
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.