#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