#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