#4977: Warning about unqualified implicit imports
---------------------------------+------------------------------------------
Reporter: Lemming | 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 Lemming):
Replying to [comment:4 simonpj]:
> Hmm. So what triggers the warning? All your examples are for a module
`Top.A`; would the warning happen if I say `import M`?
The module name Top.A is irrelevant. 'import M' shall also trigger the
warning.
> Maybe you meant to warn of any import that brings into scope a bunch of
unqualified names, unless they are explicitly enumerated. What about
> {{{
> import Top.A( T(..) )
> }}}
> Is that warned about too?
Ah, I missed that. Yes, importing constructors and class methods
unqualified and without explicit enumeration should also cause a warning.
> What is the general rule?
My intention is to warn about all import statements, that can cause the
module to break, if there is something _added_ to the imported module.
Removals and modifications of the API of imported modules are out of scope
for any warning, since we cannot protect ourselves against such changes
via the choice of import statements.
I brought the PVP into the discussion, since if you import module M with
qualification or with explicit identifier list and M is part of the
package p and p follows the Package Versioning Policy, then you can
declare
{{{
Build-Depends: p == A.B.*
}}}
in your Cabal file. If you use imports that bring a bunch of identifiers
into scope without qualification and explicit enumeration, then you have
to restrict the version range to
{{{
Build-Depends: p == A.B.C.*
}}}
Thus this warning could promote the PVP and could encourage people to
import in a way that allows larger import version ranges and thus reduce
the number of updates to packages.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4977#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
