[GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions (was: Implement warnings for class-method overriding)

[GHC]

#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  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:  #8004, #4384      |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Old description:

> This would aid long-term transitions like phasing out `Monad(return)` (in
> the spirit of #4834):
>
> With the AMP, `Monad(return)` being a class method becomes an historic
> artifact. The ideal long-term situation would rather be to have `return`
> become a top-level definition (i.e. outside the `Monad`-class),
> generalised to `Applicative` just aliasing `Applicative(pure)`, i.e.
>
> {{{#!hs
> return :: Applicative f => a -> f a
> return = pure
> }}}
>
> This may be beneficial for things like ApplicativeDo which otherwise
> would require a `return` to be handled is if it was `pure` in order to
> weaken the type-constraint in an `do`-expression like e.g.
>
> {{{#!hs
> do { x <- f; return (fst x) }
> }}}
>

> Right now, we can attach a `DEPRECATE`-pragma to the `return`-class-
> method. That however would trigger warnings on ''all'' uses of `return`,
> rather than only when using `return` in a context that requires it to be
> a class-method (like overriding `return` in instance definitions, or
> importing/exporting it via the explicit `Monad(return)`-syntax)
>
> Instead we need a way to warn about such uses of `return` which assume it
> to be a class-method, in order to phase out such uses.
>
> NB: This will probably require additional discussions, but we shouldn't
> wait too long, if we want to integrate the AMP into a future Haskell
> Report (for which we should try to clean up historic warts such as
> `Monad(return)` if feasable).

New description:

 == What?

 Implement a `DEPRECATED`-variant to be attached to method declarations (in
 `class`-definitions) with default implementations  that triggers warnings
 when

  1. When an `instance` overrides the default implementation of that
 method, and/or
  2. when such a deprecated method is explicitly im/(re)exported via
 `Class(method)`-syntax.

 But not when

  1. imported as e.g. `import Mod1 (Class, method)` (which doesn't require
 `method` to be a method of `Class`), nor when
  2. merely referring to `method` in an expression (as that doesn't require
 `method` to be a method either).

 Syntax suggestion:

 {{{
 class C a where
   foo :: a

   bar :: a -> a
   bar x = x

   doo :: a

 -- this is the new syntax
 {-# DEPRECATED C(bar) "'bar' is going to become a non-method soon, please
 avoid referring to it as a method" #-}

 -- this works already now
 {-# DEPRECATED foo "'foo' is obsolete and going away soon, please use
 'doo' instead" #-}
 }}}

 == Why?

 This would aid long-term transitions like phasing out class-methods, such
 as e.g. `Monad(return)` in the spirit of #4834:

 With the AMP, `Monad(return)` being a class method becomes an historic
 artifact. The ideal long-term situation would rather be to have `return`
 become a top-level definition (i.e. outside the `Monad`-class),
 generalised to `Applicative` just aliasing `Applicative(pure)`, i.e.

 {{{#!hs
 return :: Applicative f => a -> f a
 return = pure
 }}}

 This may be beneficial for things like ApplicativeDo which otherwise would
 require a `return` to be handled is if it was `pure` in order to weaken
 the type-constraint in an `do`-expression like e.g.

 {{{#!hs
 do { x <- f; return (fst x) }
 }}}

 Right now, we can attach a `DEPRECATED`-pragma to the `return`-class-
 method. That however would trigger warnings on ''all'' uses of `return`,
 rather than only when using `return` in a context that requires it to be a
 class-method (like overriding `return` in instance definitions, or
 importing/exporting it via the explicit `Monad(return)`-syntax)

 Instead we need a way to warn about such uses of `return` which assume it
 to be a class-method, in order to phase out such uses.

 NB: This will probably require additional discussions, but we shouldn't
 wait too long, if we want to integrate the AMP into a future Haskell
 Report (for which we should try to clean up historic warts such as
 `Monad(return)` if feasable).

--

Comment (by hvr):

 I hope this makes it more clear what I'm proposing. When I started writing
 the ticket I wasn't sure if I wanted a general facility, or something more
 adhoc for the specific AMP use-case, and so ended up with the incomplete
 description...

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10071#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler