The GHC20xx language editions seek to collect commonly-used and generally accepted extensions under a single flag. (Unlike Haskell2010, there’s no full standardization process, just the GHC user’s guide documentation.)
Given that we now have GHC2021 and GHC2024, we should start to think about GHC2027! (There’s no “official” decision to make GHC2027 the next iteration, but it would seem natural.) Which extensions would you like to see included?
To get things started, here’s my wishlist:
CApiFFI
DefaultSignatures
DerivingVia
LazyFieldAnnotations
RequiredTypeArguments (EDIT: perhaps not, given @int-index’s comments)
NumericUnderscores (if it’s not already part of GHC2024)
Regarding RequiredTypeArguments I’d encourage that you coordinate with @int-index in order to see if he feels the extension is ready for prime-time, and if it doesn’t work best with other extensions enabled.
While I’m mentioning extensions that should go together, OverloadedRecordDot and NoFieldSelectors are an absolute blast to have together, I wouldn’t want to enable one without the other!
Yes, it’s fair to say that MPTCs are a bit underpowered without either type families or fundeps. But MPTCs are a clearly reasonable common ground, whereas both additional options have different sets of dark corners around type inference. So I think for now it is reasonable to leave them both out of GHC20xx and let users enable one or both additionally when needed.
OverloadedStrings is an interesting case. It feels consistent with overloaded numbers, which have been included all along, and it might be a nice gentle nudge away from String towards e.g. Text. But turning it on can suddenly lead to confusing type inference ambiguities…
RequiredTypeArguments change the way implicit quantification works. Including them in the next language edition would break the following code:
f :: map -> map
f x = x
I have chosen map simply as an example of a term-level identifier. Currently, it ends up implicitly quantified, as if the user wrote forall map., but with RequiredTypeArguments it captures the term-level map and reports an error:
error: [GHC-45510]
• Term variable ‘map’ cannot be used here
(term variables cannot be promoted)
• In the type signature: f :: map -> map
If someone were to declare a = 42 at the top level, then f :: a -> a would stop working, too.
The first step toward enabling RequiredTypeArguments by default would be to move -Wterm-variable-capture to -Wdefault.
These steal some syntax for using # as an operator without a space character. But all of those uses should already trigger warnings by default. (Although, due to a ghc bug they don’t currently trigger a warning. So a more conservative approach would be to fix this, and let the effects take hold before enabling these by default.
I think the only real difference is that numbers have been overloaded all along, whereas strings haven’t, so existing code will necessarily work with overloaded Num and APIs have been designed on that basis. Whereas turning on OverloadedStrings may break existing code in confusing ways.
