(sorry, it's been a busy week, next email thread comes out today, or tomorrow at the latest) Joachim:
From a user-point of view, it seems you could possible merge 1, 4, 5, 6, 7 and 8 as “Developer wants access to features not on by default”. The developer probably doesn’t really care _why_ the extension is not on by default, they just want to use it when they want to use it :).
At the end of the day, an extension is either a feature that is off by
default and can be turned on, or on by default and can be turned off. I
don't think we've said much when we've reduced the users' behaviour to that
level. So I wanted this list to be specifically about the why. And I think
the users do care. GHC Proposals say “I want a new extension to support X”,
I wanted to be as exhaustive as possible to then be able to try and then
delineate the X-s that we intend language extensions to support.
On Fri, 7 Apr 2023 at 17:33, Chris Dornan
As Joachim says, "Programmers use extensions to _refer_ to a particular feature when talking/writing/searching about it."
I think this is generally important. The language reports provide the foundations for understanding the language and it is important to have a handle to describe the various departures from it -- at least until a new report around which near universal acceptance can be established.
I would extend "2. Restrict the use of more complex features" to say "2. Restrict the use of _novel_ and more complex features". I think many just want to say exactly how they are departing from Haskell 2010, whether those deltas are complex or otherwise.
Chris