.. proposal-number:: Leave blank. This will be filled in when the proposal is
accepted.
.. trac-ticket:: Leave blank. This will eventually be filled with the Trac
ticket number which will track the progress of the
implementation of the feature.
.. implemented:: Leave blank. This will be filled in with the first GHC version which
implements the described feature.
Contents
We propose to allow the syntax import M qualified
to solve hanging indents in module import lists.
To import a qualified module you must specify qualified
in prepositive position : import qualified M
. This often leads to a "hanging indent" (which is automatically inserted by some autoformatters and common in many code bases). For example:
import qualified A
import B
import C
We propose to also allow qualified
to appear in postpositive position : import M qualified
. In that case, one could write:
import A qualified
import B
import C
While a small change, this annoyance is a significant issue in many large codebases, where programmers are forced to "pick a style" - chosing to add redundant whitespace to have modules align, or to make scanning import lists harder. Additionally, the location of qualified makes sorting imports harder.
A new language extension QualifiedImportsPostpositive
is introduced. When enabled, qualified
will be accepted in postpositive positition, by updating the importdecl
production like so:
importdecl :: { LImportDecl GhcPs }
: 'import' maybe_src maybe_safe optqualified maybe_pkg modid optqualified maybeas maybeimpspec
A new warning -Wprepositive-qualified-module
(off by default) will be introduced that warns on prepositive syntax:
Preposition.hs:5:8: warning: [-Wprepositive-qualified-module]
Found ‘qualified’ in prepositive position
Suggested fix: place ‘qualified’ after the module name instead.
|
5 | import qualified Data.List
| ^^^^^^^^^
The proposed change adds the ability to specify a qualified import by placing qualified
either before or after the module name. The position of the qualified does not change the semantics, and is independent from any other import features (e.g. package imports or safe annotations). As an example, both import qualified D as E and import D qualified as E are permitted and equivalent.
There should be no other interactions with any existing language or compiler features.
The implementation of the change is but a few lines (Parser.y
for the grammar and RdrHsSyn.hs
for the warning). The increased flexibility comes with no discernible drawbacks.
The alternatives appear to be: (1) Keep the status-quo and do not allow the alternate syntax; (2) Mandate the alternative syntax and formulate a migration strategy.
The second alternative solves the motivating hanging indent issue but in our opinion both alternatives seem needlessly strict when both conventions can be had cheaply with only upside.
There are no unresolved questions at this time.
If accepted, the proposal authors will implement the change.