Is deprecation as bad as removal?

[Edward Kmett]

A deprecation definitely signals an intent to *eventually* remove.

My point was more that around that particular combinator there are a lot of
arguably legitimate users by users who aren't going to be inclined to
remove it, because it does capture their intent.

For all that a subset of the community is very vocally against the use of
partial functions like head, tail, fromJust, (!!), etc. deprecation should
send a clear signal and it doesn't strike me that the disquiet over those
combinators had risen to the level of overwhelming consent it would take to
start marking this whole style of programming as deprecated.

Now, if we want to go after supplying a warning class for partial functions
and let people opt in or out of it, that seems like another matter
entirely. It doesn't require us to put these things on a clock for removal
and folks can continue to agree to disagree about the relative merits of
this style. It would also let us go much farther and enable separately
configurable warnings across a much wider array of functions than just
fromJust.

-Edward

On Tue, Feb 24, 2015 at 6: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 :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150224/5920045f/attachment.html>