On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 09/25/2018 09:13 PM, Jonathan M Davis wrote: > > IMHO, the only time that anything along the lines of a warning > > makes sense is when the programmer is proactively running a tool to > > specifically ask to be informed of a potential type of problem where > > they > > will then go look at each of them individually and decide whether what > > the tool is telling them is valid or not - at which point, some of what > > the tool says will be followed, and some if it will be ignored. > > Yes, that's exactly what warnings are for. If people need to treat them > differently than that (ex: C++), that's a failing of the language.
As soon as warnings are part of the build process, that's not how they're treated. I have _never_ seen them treated that way. That's not to say that no one ever has done it, but I have consistently seen that what happens is that either they're either all "fixed," or they're left on, generating a wall of text. And I've seen it with more than just C++ or D (though in D, we have very few warnings, and the typical approach is to either not turn them on or to use -w, which means that you can get different semantics depending on how the code was compiled, so we end up with a different set of problems). But I honestly don't see how you can expect any project to _not_ end up with most warnings either being "fixed" or ignored when the compiler throws a whole wall of text at you about what _might_ be wrong with your program during the normal build process. If you don't "fix" them all, then you always have a wall of text, and it makes it very difficult to find the ones that matter. And if you do "fix" them, then you're making all kinds of unnecessary (and potentially wrong) changes to your code just to shut the compiler up. Sure, when a project first starts, there may not be very many warnings, but they're quickly going to spiral out of control as it increases in size unless you "fix" them all as you go along or the compiler is actually smart enough to only tell you when your code is actually wrong. And if the compiler is guaranteed to be right about it, then it should be an error, not a warning. IMHO, if warnings are part of the normal build process, then there's a serious problem with them. > Plus, other warnings (like deprecations, for example) which have proven > extremely helpful would have been a major problem had they been outright > errors. Technically, deprecations aren't warnings, and dmd treats them quite differently. They aren't affected by either -wi or -w, and from a semantic perspective, they're completely different. Warnings are something where the compiler is telling you about something that _might_ be wrong with your code. Deprecations are telling you something that _will_ be wrong with your code (but isn't yet), so you're going to have to fix it before the deprecation period expires, but you don't have to immediately. So, while the the help output from the compiler does unfortunately call deprecation messages "deprecation warnings" instead of deprecation messages, "deprecation warnings" and regular "warnings" are actually completely different, both in principle and in terms of how the compiler treats them. They're very much their own thing, and they don't have the same problems that regular warnings do. > And realistically, I, and likely most of us, frequently wouldn't have > bothered if they had been in a separate a tool, certainly not before > every commit. (Right, as if most C programmers actually *use* lint > regularly?) It's the same "built-in unittests and docs" effect. That's a valid point. A separate tool is less likely to be used, but honestly, from everything I've seen of warnings and how they've been used, I think that they do far more harm than good in general if they're just a compiler flag. And since I really think that the correct way to handle them is for a responsible programmer to proactively run a tool to figure out what problems might exist in his code anyway (just like he might choose to run a fuzzer on it to find problems), I don't think that it's ultimately a problem. Though I think that it's pretty clear that we're going to have to agree to disagree on that. - Jonathan M Davis