Re: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions

15 Jun 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