On 10/01/2018 11:00 PM, Jonathan M Davis wrote:
The very fact that we have -w causes problems, because it forks the language. e.g. anyone that doesn't compile a library with -wi or -w and then releases it with dub can cause problems when someone else uses that project and then _does_ compile with -w, because suddenly, those warnings become errors. And even if we only had -wi and not -w, the fact that the warnings are part of the compiler tends to create a culture where folks expect you to have them as part of your build and "fix" them all. So, while they _are_ a choice, IMHO, it's still a problem that they're part of the compiler, and IMHO, they cause more harm than good.
FWIW, I'm mostly with you on "-w". I've never been a fan of it and see very little point to it (like you said, it just turns them into optional errors). On the -wi, well, we disagree.
I don't want the compiler to ever be telling me something that isn't guaranteed to be a problem. Period. I am sick and tired of compilers spitting out junk that's wrong that has to be "fixed" to shut it up.
C++ seems to have really given you the wrong idea about warnings. The way it SHOULD work (and typically does in D) is that most warnings are things that YES, most likely SHOULD be fixed, but aren't worth *immediately* blocking the developer from whatever they're currently in the middle of.
Additional, more pedantic lint-y warnings can be added under separate cmdline flags. And if some shitty dev team tries to treat THOSE ones as errors, then that's on them, it's not as if taking that one thing away is going to magically turn them competent.
Deprecations are an entirely different beast, because they're telling you
Honestly, what I'm really hearing here is that deprecations are different because they're the one warning you personally aren't annoyed by...
about something that you definitely must fix, but they're not errors, because if they were, then deprecating anything would break code immediately, which would mean that we could never deprecate anything, because it would break code, and people would scream. By having it just print a message and allowing folks to either fix their code immediately or put it off, we avoid that immediate breakage. But eventually, they're going to have to fix their code or incur the breakage, which is in stark contrast to warnings, which could be useful information, or they could be utterly and completely wrong - but either way, because they get spit out as part of the build, you're forced to "fix" them.
You're mostly right about deprecations here, but largely off-the-mark on the other warnings. Again, from what you're saying here, I'm still getting the impression that you're subconsciously equating "warnings" with "C++ -Wall".
Anyway, as I said before, we're clearly not going to agree here. And we seem to just be getting less civil about the whole thing. I absolutely detest warnings, think that they have no business in compilers, and want them in a separate tool designed to help the programmer find bugs in their program and not be anywhere near the build process, whereas you like warnings, think that they're helpful more often than not, and want them to be part of the compiler.
Well, granted, that's what we seem to have gotten off-track to. But really, my main original point is not "warnings good". It's just this:
"$ toolA --do-xyz" == "$ tool-xyz" Side A: We call "warnings" Side B: We call "lint" Aside from that, there's no fundamental difference.
