Hello Committee and Community, occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default. Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module. I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them. Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)? If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely: * A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”). * Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal. This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?) * The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so. This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)? As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process! And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx. This is not a concrete (meta-)proposal, but hopefully tasty food for thought. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/