[ghc-steering-committee] #451: WARNING pragma with category, Recommendation: accept

[Joachim Breitner]

Hi,

Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:
> > But to share some color preferences: I think the x- should be in
> > the warning pragma, as currently written on GitHub. I also think we
> > will soon want to be able to put the warnings into various bins
> > (e.g. Wcompat, which seems very very useful for library writers for
> > the same reasons it's useful for GHC itself). 
> > 
> 
> 
> I'm still a bit baffled by the "x-" bit.  It just seems like extra
> noise.
> 
> Or is there an (entirely implicit) suggestion that eventually we
> might want "y-"  and "z-" prefixes, for some y and z?  


Are you baffled by the x- appearing in the flags (-Wno-x-partial) or
that they also appear in the pragmas as in
{-# WARNING [x-partial] "foobar" #-}?

The motivation for the former is namespacing: If we don't keep custom
warnings apart from those genuinely produced by the compiler, because
else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}.
(Last paragraph of section 2)

There is a suggestion to have other prefixes later maybe, to
distinguish warning categories that should be on by default from those
that should go to -Wextra or -Wall etc. (No entirely implicit, though,
section 6.3).

The motivation for the latter is that some think it’s even more
confusiong to have
  {-# WARNING [partial] "foobar" #-}
but -Wno-x-partial, because now our mental models are confused whether
partial or x-partial is the name of that warning category.


I agree that this x-foo business isn't particular aesthetic.
Alternatives:
 * We could simply allow pragmas to use built-in warning categories. 
   Maybe the library author has a good reason to group their warning
   with -Wwrong-do-bind or -Wdodgy-export
   (but it seems a rather dangerous and confusing direction.)
 * We could not require a prefix, but forbid any built-in warning
   categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).

   Then library code would have to rename their categories if they 
   (accidentially) use a category name that a later GHC version starts
   to use themselves.
 * Library authors don't get to choose category names freely, but 
   instead GHC maintains a list of allowed categories (starting with
   partial, but what else?). This would allow us to document their 
   meaning precisely for consistency, and would also allow us to set 
   their default severity (-Wdefault, -Wall etc.).

Do any of these alternatives sound better to you?


 
Cheers,
Joachim

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