| That's actually not true for java at google. However, after warning
| bankruptcy was declared, a small set were made into errors and the rest
| suppressed. So that supports the idea of categorizing warnings into serious
| and advisory, and using -Werror only for serious ones.
| Of course, choosing which ones are which is likely to be a wrangle.
Surely warning categorisation *must* be the way to go here.
Warnings vary a *lot* from things where I thought "something might be fishy here; I'd better tell the user", to "really something is almost certainly wrong, but it's legal Haskell so it can't be an error", to "this function is deprecated so at a convenient moment in the next year or two you'd better change it".
If all warnings are treated uniformly as errors that must be eliminated, the merit of having warnings, rather than outright errors, is greatly reduced. And, speaking from the compiler-writer front, instead of thinking "someone might be interested, so I'll add an optional warning", I have to worry about whether I'm going to cause lots of busy-work for library authors.
Trouble is, any particular categorisation will be slightly wrong for almost everyone. Would it help if any one organisation could list the warnings that it wanted to hear about (and then eliminate), put that in a .ghc file, OPTIONS pragma, or on the command line? So, in effect, have a per-org warning categorisation. (It would make for a very long command line.)
I'd love to find a way to make warnings more supple, less of a blunt instrument. It hurts me that what is intended as a gentle hint actually ends up disrupting our entire ecosystem!
Simon
| -----Original Message-----
| From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Evan
| Laforge
| Sent: 21 October 2015 02:06
| To: Mark Lentczner
| Cc: Haskell Libraries; Jeremy
| Subject: Re: 3 release policy
|
| On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner