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

[David Feuer]

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. But I do think we should also consider
Kris's more conservative approach.

On Tue, Feb 13, 2018 at 5: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