#4879: Deprecate exports
---------------------------------+------------------------------------------
Reporter: basvandijk | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.2.1
Component: Compiler | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
Ah, now I see. It's a bit like deprecating the "definition" of `lines` in
`Data.List`, where in this case the "definition" is the import from
`Data.String`.
But there are questions of course. What if I now say
{{{
module Foo( lines ) where
import Data.List( lines )
}}}
Do I get a deprecation message from the mention of `lines` in the export
list? What if there was no export list was `moudle Foo( module Data.List
)`?
What if something is in scope more than one way, one deprecated and one
not:
{{{
module Bar where
import Data.List( lines )
import Data.String( lines )
f = lines
}}}
Do I get a deprecation warning? Or does the use "pick the best" import
declaration?
What if something is imported two ways, and ''both'' are separately
deprectated. Does it accumulate two deprecation warnings?
What if a moudule M imports `Data.List(lines)`, and re-exports `lines`?
Is an import from M deprecated? That is, are deprecations transitive?
Thinking about it, a possible view is this:
* The existing deprecating mechanism attaches a deprecation to a
''definition'', and complains at a ''use'', but not at imports.
* The new mechanism attaches a deprecation to an ''export'' (from module
M, say), and complains at ''import'' (of module M only), but but not at
uses.
Under this interpretation it's not clear whether plain `import module M`
should do.
But regardless, there are lots of details to be worked out. Whether the
pain is worth the gain is not clear to me.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4879#comment:5>
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
