What on earth is this ticket about? The first word is "This", presumably referring to something, but with no clue about what it is referring to. I am utterly lost.
A feature request (which I assume this is) needs a specification!
Simon
Herbert Valerio Riedelchanged title from Implement warnings for class-method overriding to Implement deprecation-warnings for class-methods to non-method transitions
changed title from Implement warnings for class-method overriding to Implement deprecation-warnings for class-methods to non-method transitions
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...
Better. Syntax: why not just do this for a nested DEPRECATED pragma, thus
Works too (I'm only slightly worried that it might be confusing for users that the indentation-level of the {-# DEPRECATED #-} changes its semantics, but I have no strong preference here)
The main purpose of such a feature is to give us the ability to smoothly remove redundant class members over a deprecation cycle. (Admittedly, perhaps, quite a long deprecation cycle in the case of something like return!)
e.g. (>>) could be reduced to a top level binding to (*>) after a period with a warning making it clear that this was coming.
Other examples of candidates are Traversable's sequence and sequenceA, although there is currently a technical barrier to removing mapM entirely. This would enable us to eventually reclaim sequence for use on Applicative data types.
Having the ability to do these things means we can put together future proposals for how to move AMP (or FTP) along with reduced breakage.
I confess to not being terribly concerned about the choice of syntax, though. =)
Just found this via a libraries archive discussion. I think there are subtle cases here, if a .. wildcard is used (possibly a fishy thing in itself). With the return example, this is fine:
import Control.Monad (Monad(..), return)
This is fine providedreturn is not used or re-exported, including implicitly:
module M whereimport Ximport 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 (closed) feature-request in mind
Ok, well, please go to the specification and modify it to your satisfaction.
Remember that the existing behaviour is that import and export lists never generate deprecations. I think you want them to do so. That's ok but the specification should say so, esp as it's different to the current behaviour.