If the idea is to avoid confusion, and the `ExplicitForall` flag is currently implied by others, then shouldn't `RankNTypes`, `LiberalTypeSynonyms`, and `ExistentialQuantification` all imply `ScopedTypeVariables` instead? But that's somewhat non-obvious ...
I personally think that while the current situation is unfortunate, the
#9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 kosmikus]: proposed solution isn't ideal either. I'd keep everything as it currently is, until we get to a point where we can agree that `ScopedTypeVariables` should be enabled by default. I think it would be great if `ScopedTypeVariables` (or conceivably something even better) were eventually implied by others, or even if it came to be the default behavior in the next Report. I think the first step in any case has to be phasing out the formally useless `ExplicitForAll`; once it's sufficiently dead, that syntactic space will be entirely free for a more useful replacement. You were wise to note the problem that `ExplicitForAll` is currently implied by other flags; I think the interim solution is to add a warning when those flags are used ''without'' `ScopedTypeVariables`: "`XxxxXxxxxx` currently implies `ExplicitForAll`, which is deprecated. To avoid this warning, add `ScopedTypeVariables` and rename type variables as necessary." -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9515#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler