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

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

 * keywords:  AMP => AMP MonadFail


Old 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).

New description:

 See Design/MethodDeprecations for details

--

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