On Wednesday, December 07, 2016 02:14:38 Walter Bright via Digitalmars-d wrote: > On 12/4/2016 11:39 PM, Stefan Koch wrote: > > It will warn on something that is almost always bad! > > Warnings cause problems in that they fracture the language into different, > confusing dialects. Let's say you've joined a new group, and you're > expected to maintain some D codebase you are totally unfamiliar with. It > compiles with warnings. Is that a problem or not?
Warnings drive me nuts in C++ - especially with Visual Studio. It warns about all kinds of stupid stuff that makes no sense, much of which is perfectly valid C++ that gcc and clang don't complain about. And even when the warning does make sense, once you have to deal with 3rd party libraries, you can't rely on what warnings they were set up to work with. This is particularly fatal if the code is compiled with warnings being errors. Maybe if warnings were completely standardized, it wouldn't be so bad, but as soon as it's up to the compiler vendor, it can get disgusting fast - especially for cross-platform code. But since it's bad practice to leave warnings in your code, ultimately, they might as well be errors. And if they aren't something that should _always_ be fixed, then they have no business as warnings. Stuff that only _could_ be a problem should be left to a linter IMHO. So, I'm all for avoiding adding more warnings, though I wouldn't mind if Stefan's idea were implemented as an error in the cases where it's _guaranteed_ that the code is wrong. As soon as "might" gets involved, then the compiler should ignore it. > Every warning in the compiler is a problem with the language > specification, not a solution. +1 - Jonathan M Davis