Hi Joachim, * It seems to be inconsistent to allow both `type` and `data` in the
filtered-import, but as a qualifier on individual only `type`. Should we allow the use of `data` in import/export lists as well?
import N(f, type (++), data (+))
The "data" qualifier is also in the proposal, but it's behind PatternSynonyms rather than ExplicitNamespaces. That's because it is meant to replace the "pattern" qualifier, which is currently enabled by PatternSynonyms. However, I think you make a very good point: both of those qualifiers should be enabled by the same extension, ExplicitNamespaces.
* As discussed in https://github.com/ghc-proposals/ghc-proposals/issues/551, -XExplicitNamespaces, which is quite old and is implied by -XTypeOperators which is implied by -XGHC2021 probably ought to have been in GHC2021 as well, and I’d like to include it in GHC2023 (if that exists) to fix that (see #559). But that feels inappropriate if we extend that extension in this way.
We could side-step that issue if we put he new forms in their own language extension (maybe -XNamespacedImport)? WDYT?
#281 also modifies ExplicitNamespaces to enable inline "type" qualifiers in expressions. Do you want a separate extension for that also?