This is a bit hard for me. But here it goes.
IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus
the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having
a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should
ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to
understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that
we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion.
This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM
comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not
and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the
extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in
the same line as the Legacy/Deprecated extra complexity bucket to me.
Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_
be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have
either two separate development branches: stable + experimental (stable being periodically merged into experimental),
and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch.
And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch
migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile
time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume.
Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in
the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use
a completely separate compiler for this (again, other languages _do_ follow this approach).
And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or
learned over time that these extensions (despite being stable), have reached their end of life. In that case they should
be marked as deprecated with appropriately long deprecation cycles.
GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this
in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night
hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want
to make haskell successful, we need to make sure that in that people can be effective and productive and solve real
world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many
unknown flags, go study those flags) more than absolutely necessary to get work done.
In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable
extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative
in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion
should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_
asked for an experimental/unstable compiler.
Moritz