Disabling deprecated functions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling deprecated functions

David Feuer
The time has come to remove some deprecated functions from containers.
As many know, lots of people ignore deprecation warnings. That means
there are probably plenty of people still using the deprecated
functions.

Right now, the functions work, and give deprecation warnings telling
users what alternatives to use. If I simply remove the functions,
users will suddenly have to *actually* do something to fix their code,
but they *won't* be given any useful information about how to do it.

Ideally, GHC would add a REMOVED pragma, but I don't see any sign that
that's happening.

Pondering that conundrum today, I came up with something that seems to
*mostly* solve the problem:

-- We need this class to defer the type error to the call site, rather
-- than getting it at the definition site. I think it basically takes advantage
-- of the delayed resolution GHC uses to support overlapping instances,
-- which is kind of gross.
class Error (e :: ErrorMessage)
instance TypeError e => Error e

insertWith' :: Error ('Text "Data.IntMap.insertWith' is gone. Use
Data.IntMap.Strict.insertWith.")
            => (a -> a -> a) -> Key -> a -> IntMap a -> IntMap a
insertWith' _ _ _ _ = undefined


Now if someone is still using Data.IntMap.insertWith', they'll get an
error message, but a useful one. Great! But there are two downsides:

1. An unqualified, unrestricted import of the module will still use up
a perfectly good name for as long as the export is still there.

2. User-defined type errors have only existed since GHC 8.0. So for
earlier versions, I'd probably need to just remove the functions, in
which case the exports depend on the GHC version, which is
unfortunate.

In these *particular* cases, I suspect the benefits of this hack
outweigh the downsides, because unqualified and unrestricted imports
of Data.Map and Data.IntMap are fairly rare.

What are others' thoughts on the matter?

David
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Disabling deprecated functions

David Feuer
I just realized I can do the same thing with older GHC versions,
except with much uglier error messages. So I think I'm going to try
this out as an experiment and see what people think of it in practice.

On Tue, Feb 13, 2018 at 11:06 PM, David Feuer <[hidden email]> wrote:

> The time has come to remove some deprecated functions from containers.
> As many know, lots of people ignore deprecation warnings. That means
> there are probably plenty of people still using the deprecated
> functions.
>
> Right now, the functions work, and give deprecation warnings telling
> users what alternatives to use. If I simply remove the functions,
> users will suddenly have to *actually* do something to fix their code,
> but they *won't* be given any useful information about how to do it.
>
> Ideally, GHC would add a REMOVED pragma, but I don't see any sign that
> that's happening.
>
> Pondering that conundrum today, I came up with something that seems to
> *mostly* solve the problem:
>
> -- We need this class to defer the type error to the call site, rather
> -- than getting it at the definition site. I think it basically takes advantage
> -- of the delayed resolution GHC uses to support overlapping instances,
> -- which is kind of gross.
> class Error (e :: ErrorMessage)
> instance TypeError e => Error e
>
> insertWith' :: Error ('Text "Data.IntMap.insertWith' is gone. Use
> Data.IntMap.Strict.insertWith.")
>             => (a -> a -> a) -> Key -> a -> IntMap a -> IntMap a
> insertWith' _ _ _ _ = undefined
>
>
> Now if someone is still using Data.IntMap.insertWith', they'll get an
> error message, but a useful one. Great! But there are two downsides:
>
> 1. An unqualified, unrestricted import of the module will still use up
> a perfectly good name for as long as the export is still there.
>
> 2. User-defined type errors have only existed since GHC 8.0. So for
> earlier versions, I'd probably need to just remove the functions, in
> which case the exports depend on the GHC version, which is
> unfortunate.
>
> In these *particular* cases, I suspect the benefits of this hack
> outweigh the downsides, because unqualified and unrestricted imports
> of Data.Map and Data.IntMap are fairly rare.
>
> What are others' thoughts on the matter?
>
> David
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries