Re: Is deprecation as bad as removal?

One option is to recognize two kinds of deprecation 1. Traditional GHC style: deprecated = we will remove this soon 2. Traditional some-other-places style: deprecated = we advise against using this On Tue, Feb 24, 2015 at 6:55 PM, Greg Weber wrote:

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries