Is deprecation as bad as removal?

[Greg Weber]

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 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150224/425adff3/attachment.html>