On 2015-09-28 at 04:56:13 +0200, David Feuer wrote:
[...]
> That's an excellent idea, and I think it makes sense to offer it at the
> module level as well as the class level. Just change DEPRECATED to REMOVED
> when it's actually removed. Speaking of such, has the deprecated export
> proposal made any headway?
As far as the in-flight library proposals are concerned, I plan to
rather have hardwired specific warnings implemented in the style of the
AMP warnings as it's crucial to have them available for the GHC 8.0
release to have the foundations for the migration plans in place. We can
generalize those feature later-on (maybe even in time for GHC 8.0 if
we're lucky).
As for the more general facilities the short answer is:
They're stalled! Volunteers wanted!
There's the specification over at
- https://ghc.haskell.org/trac/ghc/wiki/Design/MethodDeprecations
and there are 3 somewhat connected/related warning-feature tickets which
ought to be co-designed to avoid obstructing each other (if there's any
risk there).
- https://ghc.haskell.org/trac/ghc/ticket/10071
- https://ghc.haskell.org/trac/ghc/ticket/2119
- https://ghc.haskell.org/trac/ghc/ticket/4879
For #10071 there's a very modest start at implementing this, which
just modifies the parser but doesn't go much farther (see wip/T10071 branch)
There's an old patch for #4879 which still works over at
- https://phabricator.haskell.org/D638
Cheers,
hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs