On Monday, December 05, 2016 08:35:34 Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/04/2016 11:41 PM, Stefan Koch wrote:
> > Hi Guys,
> > What is your opinion, should we warn if we unambiguously detect
> > something that is clearly unwanted ?
> >
> > int fn(int y)
> > {
> >
> >   int x = void;
> >   ++x;
> >   return x+y;
> >
> > }
>
> No new warnings please. If something (such as the above) is definitely wrong - the code is not memory unsafe but is definitely in error - then just issue an error. That should be done whether or not the function is used in CTFE. -- Andrei

+1

- Jonathan M Davis

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
> Hi Guys,
> What is your opinion, should we warn if we unambiguously detect something that is clearly unwanted ?
>
> int fn(int y)
> {
>   int x = void;
>   ++x;
>   return x+y;
> }
>
>  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.

Yes, but we should issue an error, like Andrei said. A language is only as useful as it's best implementation, so diagnostics like that are essential. Data-flow analysis shouldn't even be optional or lacking in any modern compiler.

On Wednesday, 7 December 2016 at 06:47:56 UTC, burjui wrote:
> Yes, but we should issue an error, like Andrei said. A language is only as useful as it's best implementation, so diagnostics like that are essential. Data-flow analysis shouldn't even be optional or lacking in any modern compiler.

you know, D has variable initialization with default values. that allows to skip DFA, and still be sure that variable is initialized.

also, that thing can be done in *backend*, if it is really necessary, along with eliminating needless loads. such warning/error absolutely unnecessary in frontend, it only adds more code to maintain, and slows down compiling.

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?

Every warning in the compiler is a problem with the language specification, not a solution.

On 12/4/2016 8:41 PM, Stefan Koch wrote:
> What is your opinion, should we warn if we unambiguously detect something that
> is clearly unwanted ?
>
> int fn(int y)
> {
>   int x = void;
>   ++x;
>   return x+y;
> }

It's an old idea, and comes up regularly.

This all sounds like a great idea, and I've tried it. Unfortunately, it runs afoul of code like this:

  int i;
  int* p = null;
  if (c)
    p = &i;
  ...code...
  if (c)
    *p = 3; // Warning Will Robinson! p could be null!

Now, one could say "improve the flow analysis to prove that the first `if(c)` is the same as the second `if(c)`. Unfortunately, `c` can be arbitrarily complex and it is one of those unresolvable problems proving that two expressions produce the same result, even if the programmer finds it obvious.

Does this happen in real code? As I discovered, yes. Often enough that I had to back out that feature.

[Other, more subtle issues like this can come from machine generated code paths that will never execute, but are difficult to not generate. So the poor schleb writing the generator has to spend a lot of time on this to work around shortcomings in the compiler flow analysis - and he'll be guaranteed to not be happy about it.]

On Wednesday, 7 December 2016 at 10:25:56 UTC, Walter Bright wrote:
> On 12/4/2016 8:41 PM, Stefan Koch wrote:
>> What is your opinion, should we warn if we unambiguously detect something that
>> is clearly unwanted ?
>>
>> int fn(int y)
>> {
>>   int x = void;
>>   ++x;
>>   return x+y;
>> }
>
> It's an old idea, and comes up regularly.
>
> This all sounds like a great idea, and I've tried it. Unfortunately, it runs afoul of code like this:
>
>   int i;
>   int* p = null;
>   if (c)
>     p = &i;
>   ...code...
>   if (c)
>     *p = 3; // Warning Will Robinson! p could be null!

Yes here it *could* be null but here it is for sure:

int* p = null;
...
// p never used here inside or outside code blocks
...
*p = 3;

So I think we can safely halt compilation with an error.

(The same goes on void example above)

On Wednesday, 7 December 2016 at 10:25:56 UTC, Walter Bright wrote:
> On 12/4/2016 8:41 PM, Stefan Koch wrote:
>> What is your opinion, should we warn if we unambiguously detect something that
>> is clearly unwanted ?
> It's an old idea, and comes up regularly.
>
> This all sounds like a great idea, and I've tried it. Unfortunately, it runs afoul of code like this:
>
>   int i;
>   int* p = null;
>   if (c)
>     p = &i;
>   ...code...
>   if (c)
>     *p = 3; // Warning Will Robinson! p could be null!

That is why I said unambiguously.
We will neither warn or error in the above case, because p could have been assigned to.
Only if we directly read from something uninitialized will we error.

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

On 12/7/2016 3:52 AM, Stefan Koch wrote:
> That is why I said unambiguously.

Ok.

> We will neither warn or error in the above case, because p could have been
> assigned to.
> Only if we directly read from something uninitialized will we error.

The dmd optimizer does global data flow analysis:

int fn(int y)
{
  int x = void;
  ++x;
  return x+y;
}

----

dmd -c test7 -O
test7.d(4): Error: variable x used before set

----

https://github.com/dlang/dmd/blob/master/src/backend/gother.c#L418

dmd's back end has done global data flow analysis since about 1985, even though popular opinion holds that clang invented it :-)

On 12/7/2016 4:40 AM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

Warnings proliferate like bedbugs in C and C++ compilers because the vendors cannot fix the language, so they more or less invent their own language by generating warnings.

As you pointed out, though, each vendor produces a different set of warnings, and trying to make code "warning portable" can be an annoying exercise in frustration.

Standardizing warnings will never work, because that means modifying the language standard, but warning were invented as a workaround for not being able to modify the standard!

Note that the C and C++ Standards do not specify any warnings.

---------------------

Warnings are useful as a first step in a deprecation process, but when people debate a language restriction, cannot agree, and so compromise by generating a warning, things have failed.