[Haskell-cafe] Deprecation being transitively reported for re-exported definitions

[Ivan Perez]

Hi

Yes. As I said, "I could re-define the exported definitions in B as
identities of those in A (easy for functions, *probably more cumbersome for
data constructors or classes*)."

For example, if B needs to re-export a record with fields and data
constructors, then you can't export those with a type synonym. You can
re-define and export the data constructor and the record fields as
functions, but then you can't do pattern matching or use record syntax on
them anymore.

More generally, the question remains. Should it work the way it does?

Cheers,

Ivan

On Sat, 14 Aug 2021 at 21:40, Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> > On 14 Aug 2021, at 9:22 pm, Ivan Perez <ivanperezdominguez at gmail.com>
> wrote:
> >
> > I have a library that is exposing too much. As a minimal example, say
> the library contains:
> > - Module A, which defines several functions and types.
> > - Module B, which exports specific definitions from module A and has
> none of its own.
>
> The simplest solution might be:
>
>         module B (somefunction)
>
>         import qualified A
>
>         somefunction = A.somefunction
>
> This creates a *new* function in B, which is not deprecated, without
> re-exporting anything from A.
>
> --
>         Viktor.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210814/8a03bb1b/attachment.html>