Hacker News Reader

Comment by WalterBright | Hacker News Reader

> 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.

View on HN

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

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.

I find that many people really dislike to put what they feel are “extra” 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.)

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.

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

Reply on news.ycombinator.com