Even if warnings are treated as errors, it is not correct because you can turn off deprecation warnings. To be fine-grained you can create a single module where deprecated things are imported and then re-exported, but that module has deprecation warnings turned off. Certainly that is extra work, but it is easier than most would imagine.

On Tue, Feb 24, 2015 at 3:35 PM, Ben Millwood <haskell@benmachine.co.uk> wrote:

I'm going to grab this quotation from a recent thread discussing removal of fromJust:

On Tue, Feb 24, 2015 at 02:32:08PM -0500, Edward Kmett wrote:

I'm personally pretty strongly against removing this function on mere
proscriptive grounds and a deprecation is effectively removal for most
users who care about warnings.

This strikes me as troubling. Are we considering deprecations to be equivalent to removals, in terms of stability impact? I've heard more than one person suggest that we are, or should. The argument for it is reasonably clear: with -Werror enabled, as many people do, as many would encourage, even, either removal or deprecation of something you use will break your build.

But surely the *entire purpose* of deprecations is to be *less* damaging than removals, and so if we're implicitly considering them equally bad, that suggests to me that our deprecation mechanism is totally broken, and needs to be fixed.

I can think of several potential fixes, but I'd first like to see if others agree that there is a problem :)
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries