"There is no point in not supporting it" is not "it is supported" though. The former is an opinion, the latter is simply false.

And the former is the meaning of TFA, the latter is a fictional alternative intention of TFA where it fails to meet the standards of truth.

The technical reason is that it makes the compiler a lot more complicated.

I've implemented this for calls in a single-pass compiler and it is really simple. You just treat the yet-undeclared call as if it was used correctly and add it to a list of calls to check later.

Compared to everything else a compiler needs to do this is trivial.

Doing it for types is harder though as far as single-pass compilers are concerned. Both are much easier if the compiler builds a syntax tree (or at least a list of all declarations even if the function bodies are handled at a later pass) ahead of time though.

That doesn't work if definition is part of a different compilation unit. 99% of functions in C will be (libc, other system libraries you may be using, etc.).

It hinders single-pass in just the same fashion as types do. Consider:

    f() { g(1); }
    g(x) double x; { printf("%lf\n", x); }

You have to know the type of g's parameter before you can generate code for f.

(that function definition would be "void g(double x) { ... }" in non-obsolete C)

As another commenter pointed out, this is obsolete C, however: this is just not how modern compilers work. at all. Compilation is performed in phases, you have syntax analysis, semantic analysis, and then optimization and codegen. It’s trivial for a compiler to handle this code, heck C++ compilers (which your C compiler is under the hood) already do this for struct/classes (allowing member functions to be called before being declared). Pretty much every other language supports this too, but universally and not just in classes. We’ve come a long way since the 60’s.

> Compilation is performed in phases

In this context, it isn’t. The comment you replied to was a response to the statement:

> I've implemented this for calls in a single-pass compiler and it is really simple. You just treat the yet-undeclared call as if it was used correctly and add it to a list of calls to check later.

Looks like you missed the point.

The k&r-style function definitions apparently amused only me, but are beside the point regardless.

Single-pass compilation is very pertinent. One tenet of c's design is that it should be compilable in a single pass (which is why it is compilable in a single pass, unlike many other programming languages). This is relevant to us because it allows us to make predictions about the language; in particular, if the addition of some feature would cause c to not be compilable in a single pass, we can predict that the feature will not be added to the language. Notice that I have not made any value judgments. You may disagree about the importance of supporting single-pass compilers, but I am not the person you need to convince of that.

It's the checking later bit that can cause issues.

You need to be able to (ideally) treat compilation as a dynamic schedule rather than a static list of passes.

D needs to do that because it's weird. I don't see why c would, in order to have forward references. It doesn't do inference or have any fancy compile time features.

I guess but allow me to nudge towards the more interesting problem rather than just writing 1 more ISO C compiler with a slight modification.

Complicated for the single-pass PDP-11 compiler.

Everything else that can fit AST in RAM can do it relatively easily. Modern C compilers have millions of lines and hundreds of person-years of work in them, so two passes and a lookup table is not a big deal.

It's just not done because the C standard doesn't say it should. Perhaps there is some preprocessor crime that this isn't compatible with, or they just don't want to break that PDP-11 compatibility.