Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> My only question is: do we really need a flag. Suppose we simply
> accepted the postfix “qualified” with no flag support. Then a
> program will be accepted that earlier compilers would have rejected –
> and, absent a flag, we normally try to continue to reject programs
> that weren’t legal before. But in this case no one is going to fall
> into this by mistake. I suggest we consider simply allowing it as an
> exception to our general rule, and move on.
Let’s not do this. We have very few hard guidelines to help us in our
work; “changes to the language needs a flag” is one of them. If we
start to be lax here, we will have to justify every future flag where
the extension would just be an invalid program otherwise, including
things like LambdaCase etc.
It is tempting, but the slope is too slippery.
Most of our users (in particular the “experienced users” mentioned
above) are used to managing a long list of flags, adding another will
not hurt them to manage another one.
And if this management becomes too long, then instead of making
exceptions, we should either hope for Haskell20xx to liberally include
these “convenience extensions”, or otherwise make the management of the
extension list easier (e.g. maybe by picking up
https://github.com/ghc-proposals/ghc-proposals/pull/92 again).
Yes - everything that changes the language in some way should have an extension flag. We've been strict about this up to now, I think it would be a shame to start making exceptions. We have the nice property that if a module would fail to compile because it uses an extension that isn't supported by the compiler in use, we get a useful diagnostic rather than just a parse error. Every source file declares which language it is written in (well, together with the .cabal file), which is a nice property to have, and useful for other tooling in addition to compilers.