[GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions
GHC
ghc-devs at haskell.org
Mon Jun 15 08:58:24 UTC 2015
#10071: Implement deprecation-warnings for class-methods to non-method transitions
-------------------------------------+-------------------------------------
Reporter: hvr | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler | Version: 7.8.4
Resolution: | Keywords: AMP
Operating System: Unknown/Multiple | MonadFail
Type of failure: None/Unknown | Architecture:
Blocked By: | Unknown/Multiple
Related Tickets: #8004, #4384, | Test Case:
#4879 | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by hvr):
* related: #8004, #4384 => #8004, #4384, #4879
Comment:
Replying to [comment:10 simonpj]:
> I have attempted a precise specification, in
[wiki:Design/MethodDeprecations]. See if you agree with it.
I think so. However, you added this code example:
{{{#!hs
module Use where
import Def( C( bar ) )
import Def( bar )
x = bar ()
}}}
which should definitely be complained about (if `bar` is deprecated-as-
method-of-C), as this code would break as soon as `bar` moved out of `C`
for real.
>
> What about this? (Using the main example in
[wiki:Design/MethodDeprecations]
> {{{
> module M where
> import X
> import M1 ( C(..) )
> x = bar ()
> }}}
> Do we get a warning here? You might say that since `X` doesn't export
`bar` (which is not obvious) that the only way it can be in scope is via
`C(..)`.
> I say yes, and I have articulated that in the wiki page. There is a
design alternative described there too; I'm not sure what you want.
That's indeed a not so clear case, but I'd consider this a case where we
need to warn, as the assumed use case for this new deprecation is that
such methods will eventually be *moved* outside the class, but with the
intent to remain exported (but not belonging to `C` anymore) from that
very module that currently exports `bar` as method of `C`.
PS: ...and I forgot to mention that this feature should be implemented
(and data types refactored) while keeping the related #4879 feature-
request in mind
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10071#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list