Should we warn if we detect null derefernces or void value uses ?

[Jonathan M Davis via Digitalmars-d]

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