I'm in favour.

For the bikeshedding question, the mathematician in me believes that using `WARNING [partial]` is more canonical. Except that there is the `deprectations` category which is suppressed with `-Wno-deprecations` (the proposal solves this in saying that `-Wno-deprecations` is actually an alias for `-Wno-x-deprecations`, why not). Pragmatically, though, the more I think about it, the more I'm favouring enforcing that the warning author write `WARNING [x-partial]` (it is also permitted to write `[deprecations]` without an x, which would avoid introducing `x-deprecations` gratuitously). The explicitness here, I think, helps. The warning category would _always_ be called `x-partial`. It's easier to process, easier to google. The cost is tiny.

As to the other question: we probably shouldn't permit warnings to join other warning categories: they are documented in the user guide, and having one of these warnings trigger for another reason can be potentially quite confusing. Not every category anyway. Maybe we will find some that can be sensibly extended. Forcing `WARNING [x-partial]` allows us to whitelist categories that can be extended with custom warnings.

I don't think that the other alternatives in the proposal need to be addressed at this point (if anything, I think they are better addressed when we have more information on how people actually use these new categories, instead of just guessing what the pain points will be).

/Arnaud

On Wed, 16 Nov 2022 at 20:16, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear all,

Adam has submitted “WARNING pragmas with categories” for committee
consideration:
https://github.com/ghc-proposals/ghc-proposals/pull/541
https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst

I’m shepherding that one myself.

WARNING pragmas can come with categories now:
   {-# WARNING [partial] head "This is a partial function, …" #-}

so that one can sensible group them and allow the user to silence the
warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
like with the built-in warning categories.

No language pragma is required (presumably since we are already in a
GHC-specific pragma).

These custom warnings categories need to be prefixed with `x-` on the
command line to keep them separate from the built-in warnings. This is
a decision where I am inviting the committee to bikeshed:
* Do we really need a separator, or is it ok for library-defined 
  warnings to join a built-in category?
* Should it be used in syntax as well (WARNING [x-partial]) for easier 
  predictability and later extension to other prefixes (see below)?

All these custom warning categories are part of the severity group
-Wdefault (on by default, not errors). I expect we eventually want to
give the programmer control over the severity (off by default, error by
default, part of -Wcompat, etc…), but it’s not immediately clear what
to do here, so we can add it latter (another optional field in the
pragma, a separate pragma, a naming convention like xe-foo, or
something else).
Please complain if you think this needs to be addressed here.

Cheers,
Joachim


--
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee