Hacker News Reader

Comment by WalterBright | Hacker News Reader

The trouble with warnings is they inherently balkanize the language into multiple incompatible and even contradictory languages.

Warnings arise from being unable to modify the language semantics. But even if you can modify the semantics, warnings are spawned as a compromise when people cannot agree on what the language semantics should be.

I've tried pretty hard with the D programming language to not have any warnings - that the semantics should be firmly decided upon. Some warnings still have crept into the compiler, but fortunately just a handful.

View on HN

No matter what your language semantics are, there will still be different styles of coding. It's extremely valuable to shepherd your codebase into a particular paradigm for readability reasons.

That said, style warnings are incredibly hard to detect and enforce (e.g., -Weffc++ is so noisy I've never been in any codebase where I could leave it on)

Style warnings are something else entirely. The warnings I'm talking about are for code that looks suspiciously like a bug.

> Warnings arise from being unable to modify the language semantics

Not always. For instance, C has a lot of stuff around casting, memory management, etc. that is semantically legal but often good to warn about. Other times, it can warn about a possible stack overflow. C has tons of behavior which is not technically defined but has been agreed upon by most compiler implementers (and doesn't warn), though admittedly, there are also cases where you'll get different results.

> Not always. For instance, C has a lot of stuff around casting, memory management, etc. that is semantically legal but often good to warn about.

That's just what I meant. Can't change C, so issue a warning. For example,

    for (i = 0; i < 10; ++i);
        sum += i;

My C compiler warns about the ; and the D compiler gives an error for it. A number of common C warnings are just flat out errors in D. For another example,

    if (a < b < c)

likely will produce a warning in C, but it won't even parse in D (I fixed the grammar so it is not a valid construction).

The fact that these pointless and buggy constructs persist in C is evidence that the language cannot be changed, hence a warning is used.

An even better solution for the "for" example is enforcing the curly braces around every block. Simple rule, no heuristics to catch such bugs.

I find that many people really dislike to put what they feel are “extra” braces.

and then it bites them in the ass when they need to add another line later on.

I've been writing C and C++ for thirty years and I've made many mistakes but never that one. I suspect it's far more common if an always-uses-braces programmer edits an optional-braces code base. I'm not religious about it though. If the Romans are wearing braces I'll wear braces.

Getting worked up over a non-issue is counter-productive (to be clear: it is fussing over the 'extra' braces that is the non-issue; having an explicit syntax for the empty statement is an issue, and one that makes sense.)

They are extra braces. The C grammar allows any statement as the body of a control structure. Compound statements are only one of the possibilities. Just because other C-like langs have different grammar requiring the braces doesn't mean C has to look like them too.

Just to be clear, D doesn't require extra braces. It just doesn't allow an empty statement terminated with a ;.

    if (x) foo();  // accepted
    if (x) ;       // rejected
    if (x) { }     // accepted

It's not a heuristic in D. The grammar was adjusted so having a ; denote an empty statement is not part of the grammar. Hence,

    if (x);

etc. are also rejected. If you actually want an empty statement, { } does the job. Doing it with the grammar is not hackish and it works out quite nicely.

I'm guessing that was a design goal from day one? How hard has been to maintain that goal, as any slip up will become just as hard to fix as in C, right?

D has been more accepting of changes to fix bad design decisions than C has. The ; thing was there since day 1, the rejection of (a < b < c) came later - nobody objected to it.

Is that a property of the D community being younger (the community itself, rather than the people in the community) and smaller than C and C++ communities. Or is it something more culture based. Any ideas?

That's a great question. It seems to be a property of the D community wanting the language to get better and being willing to accept change.

In the olden days (1989) people were more willing to accept change in C, such as value-preserving rather than sign-preserving integer promotion rules, and some improvements to the C preprocessor.

I have Visual Studio configured to warn on blocks without braces. It finds a bug about once every two years.

Another argument (which I remember coming from Walter): The job of the compiler is to generate code. It's job is not too serve as a half-assed static analysis tool.

Today a compiler is not the only tool to parse a language anymore. It sure is convenient to add some print statements where the compilers sees the warnings anyways. A better approach is to provide the frontend as a library to allow plenty of other tools, e.g. a formatter.

I think the "the compiler is not a static analysis tool" is a viewpoint that is fighting against the in-practice user-experience that reporting of problems in the code is more effective the earlier in the feedback loop it happens and the more guaranteed it is that the issues are noticed [X]. So having an automated static analysis report delivered as comments into a code-review system is better than after-the-fact offline static analysis, but "the compiler tells you about the problem as soon as you try to build the code" is better still. Lots of people don't run static analyzers, but everybody runs the compiler. (This doesn't mean that you need to structure the compiler internally to do everything at the same time rather than as separate compile and analyse passes -- just that the command your users use to compile should include the production of static-analysis type issues at the same time and in the same error-message format as it would for stuff like syntax errors.)

[X] for a reference backing this up see the part of Facebook's ACM article on static analysis https://cacm.acm.org/magazines/2019/8/238344-scaling-static-... in the section titled "Human factors"; there they compare "after-the-fact offline analysis" with "in the code-review system", and I think the same reasoning applies to comparing "in the compiler immediately" against "later in the code-review system".

Who says that static analysis happens "later in the code-review system"? Static analysis does not equal (slow) data flow analysis.

Actually, most people have a (very weak) form a static analysis which happens before the compiler: syntax highlighting. This can be expanded such that type checking and similar fast checks are integrated into the typing feedback loop.

In my ideal world, the next (slightly slower) feedback loop should be the unit test which the developer is currently working on/against.

Only the third-fastest feedback loop is a full compilation where compiler warnings would matter.

Reply on news.ycombinator.com