Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap

[Matt Renaud]

> avoiding these subtle bugs requires at least a full GHC release cycle

Now that GHC is on a 6 month release cycle this seems preferable to waiting
3-5 years.


On Tue, Feb 13, 2018 at 2:52 PM, David Feuer <david.feuer at gmail.com> wrote:

> It would let us have some cake. Users would be able to test against 0.9,
> in theory. But they'd have to do it intentionally. And Stack-based projects
> would probably need some shenanigans to deal with a version of containers
> that doesn't come with GHC. So I really think that avoiding these subtle
> bugs requires at least a full GHC release cycle.
>
> On Feb 13, 2018 5:48 PM, "Herbert Valerio Riedel" <hvriedel at gmail.com>
> wrote:
>
> Hi,
>
> On 2018-02-13 at 17:41:25 -0500, David Feuer wrote:
> > We may not have to be *quite* as long-winded as I initially suggested,
> > but I don't think your way is sufficiently long-winded. The advantage
> > of removing the instances first and then adding them back is that the
> > version(s) without the instances will make compilation of every single
> > package that uses them fail. The way you suggest, if someone has a
> > package using containers or unordered-containers, they don't even have
> > a simple way to find out whether they need to make changes. On the
> > opposite side, Chris Wong's suggestion would let us be very explicit,
> > with a type error that warns users that the instance is missing
> > *because it is changing* and that no code using the instance will work
> > for both 0.* and 1.* versions.
>
> Alright, then let's do a little Gedankenexperiment; what if you release
> a containers-0.9.0.0 (which drops the instances) and a
> containers-1.0.0.0 (which 'adds back' the desired new instances) on the
> same day!
>
> ...wouldn't this allow us to have the cake and eat it too? ;-)
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180213/4cbfa96d/attachment.html>