Is deprecation as bad as removal?

Greg Weber greg at
Tue Feb 24 23:55:18 UTC 2015

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 at>

> 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 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list