https://issues.dlang.org/show_bug.cgi?id=17424
--- Comment #4 from Eyal <e...@weka.io> --- (In reply to Jonathan M Davis from comment #2) > (In reply to greenify from comment #1) > > Great idea. This is one of the areas where D is definitely behind other > > languages. > > IIRC Walter believes that the compiler isn't a linter, so if I am not > > mistaken only warnings with minimal or zero overhead will be merged. > > His take on it is that warnings are a sign that folks couldn't agree on what > was right or wrong in the language. He tends to think that something should > either be an error or not (and I agree with him). But the issue of warnings > has been discussed many times in the newsgroup, and I really don't think > that many are going to be added to the compiler. And the fact that dmd > stupidly has -w makes them that much worse because of how that affects > compile-time introspection. And folks indeed can't agree, and for good reason! Different people assign different importance to correctness vs. convenience. I agree that "warnings" should always actually be errors (-Werror) - but we will never reach consensus on what the set of warnings should actually be. And of course, they shouldn't affect __traits(compiles, ...) and is(typeof(..)). If someone uses D for small <3-5KLOC projects, where a build-test-debug-cycle is 10 seconds and a bug is a minor nuisance, of course he wants convenience. Emphasis on correctness is not worth the hassle. We use D for a large project, with a much much slower build-test-debug-cycle. Bugs easily cost us hours. Detected late, they can cost us days. Undetected, they can be disastrous. Our trade-offs are different, so there is no one-size-fits-all. And this is why a language that wants to cater to both of these audiences should have flags. > Ultimately though, the big problem with warnings is that if you're doing > your job right, you fix them all (if you don't, you just end up with a big > pile of warnings that get ignored and so you miss whatever value they do > provide), and so you might as well either make them errors or not warn about > them at all. And it gets _very_ annoying when the compiler warns about > something that shouldn't need to be changed. Really, anything that's going > to be optional makes far more sense in a linter. I don't want multiple tools to spend time CTFE'ing my code and increase an already long debug cycle. Perhaps reframing the discussion from "warnings" to "optional errors" is better. > _Best_ case, > you're stuck "fixing" all kinds of stuff that isn't actually wrong so that > you don't have any warnings, This is the case for me everywhere I had the ability to set the warnings policy (-W<kitchen sink> -Werror). This is a *cheap* price to pay, compared to a single unexpected week lost to a completely unnecessary bug. > but more often, you end up with tons of > warnings that no one pays attention to. Having at tool that can warn about > potential problems has real value, but I don't think that it's appropriate > for the compiler to be doing it. Agreed. That's why "optional errors" is how I should have framed it, and not "warnings". > Walter is also very much against additional compiler flags. So, I think that > you're going to have a hard time convincing him that this is a good idea. > Having the compiler as a library as has been discussed would make it easier > to write a linter, but based on past discussions on this topic, I think that > it's pretty clear that the vast majority of these suggestions will never be > compiler warnings even if they make a lot of good sense for a linter. One-size fits all is going to be bad for one group or the other. Compiler flags are bad for the compiler's manpage. --
