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

[Matt Renaud]

+1 to HVR's suggestion, this could be a great opportunity to clean out all
the old cruft from the containers and unordered-containers APIs in one go.
That combined with all the documentation improvements would warrant a
1.0.0.0 for both packages IMHO :) I'd be happy to help with figuring out
what that 1.0.0.0 API could/should look like, since it should almost
certainly include a lot of community input/feedback.

On Tue, Feb 13, 2018 at 2:28 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> David,
>
>
> On 2018-02-13 at 14:33:45 -0500, David Feuer wrote:
>
> [...]
>
> > 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map,
> > Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of
> > containers and unordered-containers.
> >
> > 2. Remove the deprecated instances.
> >
> > 3. After another several years (four or five, perhaps?), make a major
> > release of each package in which the instances are replaced with the
> > following:
>
> Why does this need to be a such a dreadfully long-winded process? All we
> need is a way to somehow signal a semantic change in the exposed API --
> and it turns out that we actually already have the technology for this!
>
> This is exactly one of the core ideas of "semantic versioning" (as a
> dep-solver-computation-friendly proxy for machine-checkable formal API
> contracts...) and it's got even "semantic" in its name!
>
>
> In other words, the proposal can be greatly simplified to
>
>
> 1. Make a new major release (or maybe even make it a super-major
>    release, i.e. to `containers-1.0.0.0` for extra saliency) replacing
>    the instances with the more desirable ones; describe the change
>    prominently in the changelog.
>
>
> Profit!
>
>
> Life's short; do we really need a multi-generational journey where the
> original supporters may not even be around anymore to see the proposal
> reach its final destination... ;-)
>
>
> Cheers,
>   HVR
> _______________________________________________
> 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/08624071/attachment.html>