Modules don’t import everything.

In Python, import is an act of bringing in everything into the namespace (under its own or otherwise).

In compiled languages, it is the act of making it available within this compilation unit. Things that are unused are stripped out and only what you either use or re-export have an effect. That is of course for static binaries, for dynamic linkage none of it really matters.

In fact modules can be more efficient than headers, because the way C/C++ work is that everything within the header file is verbatim copied into the file referencing it. This isn’t true with modules.

>"As far as I know, header files came to be because when C was built disk space was at a prime and storing libraries with their full source code would be expensive. Header files included just the necessary to be able to call into the library while being considerably smaller."

This claim doesn't make sense to me. You don't want and can't include the implementation in multiple C compilation units because the symbols from them would conflict. I suppose if you include the existence of shared libraries as a means of saving disk space the assertion isn't wholly wrong, but I've never see anyone make such a claim before.

Headers exist even within a C project so that the various parts of it can share the function prototypes and struct definitions while being independently compiled.

Unitit builds where you do include everything exists. They have pros and cons.

I've never heard of unity builds including everything together. I'm not aware of a build system which even does that by default. If you enable unity in CMake, it groups batches of 5 files together by default, and the documentation discourages users from including everything in a single translation unit.

sqlite calls it an amalgamation build. Whole program building certainly exists. It doesn't explain where the quoted poster got the idea that headers were intended to save space rather than allow for independent compilation.

IIRC the main point of header files was to make compilation 1 pass instead of 2. I.e. when the compiler is processing a function and sees `int a = foo(bar, baz);` how does it know what code to generate here? How do you call foo (i.e. what calling convention does foo have)? Furthermore, how do you know if the code is valid? Do the passed arguments match the declared arguments? What if there is function overloading? How does it know which actual function to call? A lot of other compilers will do two-passes where they scan the code once to compile all of that information, and then do it a second time to then actually write the code out. The optimization for c/c++ was to "cache" the declarations separately in a header file, so that you dont need to parse/scan twice.

Header files were an obvious and easy hack for the compiler writers. We don't want to duplicate these declarations in every file. Just put them in a file, and use the magic "#include foo.h" to read the file in at compile time.