On Wed, 07 Dec 2016 04:40:02 -0800, Jonathan M Davis via Digitalmars-d wrote:
> Maybe if warnings were completely standardized, it wouldn't be so bad,

Warnings that depend on flow analysis will be a problem. You can't write a compliant compiler unless you implement this level of flow analysis -- but then it's a problem if any compiler produces better flow analysis!

On Wednesday, December 07, 2016 22:10:57 Chris Wright via Digitalmars-d wrote:
> On Wed, 07 Dec 2016 04:40:02 -0800, Jonathan M Davis via Digitalmars-d
>
> wrote:
> > Maybe if warnings were completely standardized, it wouldn't be so bad,
>
> Warnings that depend on flow analysis will be a problem. You can't write a compliant compiler unless you implement this level of flow analysis -- but then it's a problem if any compiler produces better flow analysis!

Well, if the code is unambiguously wrong, and it's just that some compilers catch it and some don't, I'm not sure that that's a big deal, since as soon as one compiler catches it, you know about it, and you fix it, and since it's definitely wrong, there should be no problem with fixing it. But it must be unambiguously bad code, or it definitely is a problem.

- Jonathan M Davis

On Wednesday, December 07, 2016 05:14:47 Walter Bright via Digitalmars-d wrote:
> Warnings are useful as a first step in a deprecation process

Yeah, but at this point, we have a separate mechanism for deprecations, and it doesn't stop compilation (as originally happened with deprecations), making warnings unnecessary for that.

> but when
> people debate a language restriction, cannot agree, and so compromise by
> generating a warning, things have failed.

Definitely. And I think that the mess with C++ and warnings is proof of that.

- Jonathan M Davis

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
>  This requires data-flow analysis (The same kind that tells you if you are skipping a statement)
> And will slow down compilation a little if we enable such a warning.


I would rather see a separate tool for stuff like this. It can be much slower and do much more analysis.

Compare: clang-analyzer http://clang-analyzer.llvm.org/

On Thursday, 8 December 2016 at 08:52:45 UTC, qznc wrote:
> On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
>>  This requires data-flow analysis (The same kind that tells you if you are skipping a statement)
>> And will slow down compilation a little if we enable such a warning.
>
>
> I would rather see a separate tool for stuff like this. It can be much slower and do much more analysis.
>
> Compare: clang-analyzer http://clang-analyzer.llvm.org/

Due to D's stronger focus on correctness,
something like the clang static analyzer has importance in D then it has in C++.

Also If we don't stick to unambiguous errors, there will be a LOT of false positives.