[GHC] #1460: Problem with Monoid instance of Data.Map

[GHC]

#1460: Problem with Monoid instance of Data.Map
-------------------------------------+-------------------------------------
        Reporter:  ahey@…            |                Owner:  (none)
            Type:  proposal          |               Status:  closed
        Priority:  normal            |            Milestone:  Not GHC
       Component:  libraries/base    |              Version:  6.6.1
      Resolution:  fixed             |             Keywords:  Data.Map
                                     |  Monoid
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by andrewthad):

 I absolutely agree that making the change in a way that silently
 introduces errors would be bad. That's why my proposal was to remove the
 instance first and then replace it later. With a major-version bump, the
 `Monoid` instance would be removed entirely. Then, everything depending on
 in would fail loudly. There would be no `Monoid` instance at all for
 probably 18-24 months. Let's say that it was `containers-0.6.0` that
 removed the instance. Eventually, stackage, nixpkgs, and the Haskell
 Platform would all pick up `containers-0.6.0` and put some pressure of
 their users to stop using the `Monoid` instance for `Map`. Then, after
 everyone's code was updated, the next release could introduce the new
 instance.

 Most of the breakage would be really easy to fix. Additionally, it should
 all be compile-time failures. The only silent breakage that could happen
 would be if someone didn't update their dependencies for two years and
 then tried to switch straight from the old `containers` to the newest one.
 I suspect this situation would be uncommon (although, as someone would is
 primarily an application developer, I certainly cannot speak for everyone
 on this, and I may be wrong about this, which would destroy my argument
 for this approach).

 So basically, I just wanted to clarify that while there would be breakage,
 none of it would be silent. Obviously, this still has to be weighed, but I
 think it's much less bad than the undetectable semantic changes you
 describe.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler