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"
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? ;-)