#4879: Deprecate exports
---------------------------------+------------------------------------------
Reporter: basvandijk | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by basvandijk):
Replying to [comment:1 simonpj]:
> How does this differ from what we have now? You can say
> {{{
> {-# DEPRECATE lines "Exported from Data.String instead" #-}
> }}}
> in `Data.List` and it will work just as you say. Maybe you can
elaborate your proposal to say how it relates the current mechanisms?
The current mechanism allows you to deprecate a ''definition''. I would
like to deprecate an ''export''. In the case of `lines`, I would like to
move the definition of `lines` to `Data.String` and re-export it from
`Data.List` so that user code doesn't break immediately.
However, I do want to mark the export of `lines` from `Data.List` as
deprecated so that users are warned that in the next version of `base`
they need to import it from `Data.String`:
{{{
module Data.String
( ...
, lines
...
) where
lines = ...
}}}
{{{
module Data.List
( ...
{-# DEPRECATE lines "Exported from Data.String instead" #-}
, lines
...
) where
import Data.String ( lines )
}}}
We could keep the definition of `lines` in `Data.List` and deprecate it
and define a new function `lines` in `Data.String`. However this has the
disadvantage that users importing both `Data.List` and `Data.String` get
an "ambiguous occurrence of `lines`" error unless they use qualified
imports.
In the proposed mechanism we don't have this problem and there's no need
for a duplicate definition.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4879#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
