The trouble with warnings is every compiler has a different set of warnings. It balkanizes the language. Many D features are the result of cherry picking warnings from various compilers and making them standard features.

I see this as a feature, not a bug. I compile my code with a range of different compilers because each one catches things the others don't. The creeping gcc-isation of everything is what I'd see as a bug.

> It balkanizes the language.

Not really, as C has had even more diverse implementations per-standardization. I would say the situation is now, much less diverse under the rule of GCC and Clang. (Yeah MSVC also exists.)

Every switch that changes the language semantics creates a separate language. If you have n such switches, your compiler is supporting n x n languages. I've also had troubles writing portable C code with all warnings enabled as different compilers contradicted each other on what was acceptable.

I tried pretty hard to make D a warning-less language, but still some crept in grump grump.

Have fun with this one:

    for (int i = 0; i < end; ++i);
        foo(i);

One of the best programmers I know came up to me with this loop and told me my C compiler was broken because the loop was only executed once. I pointed at the ; and you can guess the rest.

I added a warning for that in the C compiler, and for D simply disallowed it. I've noticed that some C compilers have since added a warning for that as well. The C folks should just make it illegal.

I've also fixed printf in D so that:

    char* p;
    printf("%d\n", p);

gives an error message, and the right format to use for `p`. It was a little thing, but it sure found a lot of incorrect formats in my code.

> The C folks should just make it illegal.

I often have code, which looks like this:

    for (ptr = start; random_condition (*ptr); ptr = ptr->next);
    for (ptr = ptr->next; other_condition (*ptr); ptr = ptr->prev);

    ...  [do action]

    for (ptr = end; to_be_deleted (*ptr) && (delete (ptr), TRUE); ptr = ptr->prev);

I wouldn't be happy about your policy.

> I've also fixed printf in D so that [...] gives an error message

Just last week I had the case that the C compiler complained, I should use %lld for long long, but the printf implementation shipped with the compiler doesn't support that. Thus, using %ld, even if undefined behaviour was the correct action. I wouldn't like my language making up more work for me for no reason.

Rewrite as:

    for (ptr = start; random_condition (*ptr); ptr = ptr->next) { }

Then anyone reading your code will know the empty loop was intentional. BTW, many C compilers warn about the ; on a for loop.

Have you ever discovered this bug:

    if (condition);
        doThis();

It's a hard one to see in a code review. Yes, that's also disallowed in D.

> I should use %lld for long long, but the printf implementation shipped with the compiler doesn't support that.

Weird that your compiler would support long long, but with a broken Standard library. I don't see that as a feature. You can always cast the argument to long, and at least you won't get undefined behavior.

> Rewrite as:

Could do that I just don't like the look. :-)

> Have you ever discovered this bug:

Actually no, because the coding style I use either puts it on a single line or with braces. I never indent just a single line.

So:

    if (condition) doThis ();

or:

    if (condition)
    {
        doThis ();
    }

> Weird that your compiler would support long long, but with a broken Standard library.

Yeah, for your information it was GCC combined with newlib for arm-none-eabi shipped with Debian/MS Windows.

> So or

Those are not what I was mentioning. It was the use of ; immediately following for(). No loop body.

That was the answer to your:

> Have you ever discovered this bug: [...]