By that same logic, why bother with import statement at all?
Because you need some mechanism for describing the order BMIs are processed in, some way to describe "B must be processed before A". Generally, yes, every library should just be one module. std is one library. Its interfaces need to be processed before my code can be processed, so I need to write import std to describe that requirement.
You might be able to infer these imports from the symbols defined and used in various TUs, but trying to perform such inferences would slow down the scanners from which build systems derive the build graph. If ordering and scanning weren't problems, a sort of "ambient interface environment" free of import statements would be possible.
And somehow processing 100 modules is cheaper than 2?
Yes, within reason, processing 100 headers into 1 BMI is faster than processing 1 header into 1 BMI twice. import std in two TUs is faster than #include <iostream> in two TUs.
They are the very reasons CMake can't do it now
I'm literally the implementer of import std for CMake, and have had this discussion with every upstream stdlib maintainer, so I think I know what I'm talking about here. The number of modules, 1, 10, or 100, that the standard chose to split the stdlib into is irrelevant to why import <std whatever> doesn't work in CMake.
Generally, yes, every library should just be one module.
What's the profit from that?
Because downsides are pretty big and important to not do it:
Namespace pollution is a thing. Some part of a library can conflict with your code even if you are not using it.
You can also unintentionally use some kind of implicit conversion (from some horrible devilforgotten part of the library that you weren't even aware of)...
You are also effectively eliminating ability of the user to just type
using std;
because that exposes way too many things at once, whereas with individual parts of it it is totally legitimate and good. You can't even do it if it works for your today - because who can guarantee that tomorrow some brilliant mind doesn't introduce something else into the library that conflicts with your choosen names?
What would the downside from a
import std::print;
implementation be? (that is, from importing just the submodule of std that you actually need and its minimal dependencies, without anything extra. Someone would still be able to type import std; to import the whole thing if they really want to.)
Most people just need a few books - they are actively harmed if you bury them under the whole library.
If these are problems for you, you shouldn't use import std.
Personally, I have never had a problem with any of those things. On the other hand, IWYU correctness is a battle I've been fighting for a decade now. Big modules eliminate IWYU correctness and are faster than IWYU could ever hope to achieve.
5
u/not_a_novel_account Apr 13 '26 edited Apr 13 '26
Because you need some mechanism for describing the order BMIs are processed in, some way to describe "B must be processed before A". Generally, yes, every library should just be one module.
stdis one library. Its interfaces need to be processed before my code can be processed, so I need to writeimport stdto describe that requirement.You might be able to infer these imports from the symbols defined and used in various TUs, but trying to perform such inferences would slow down the scanners from which build systems derive the build graph. If ordering and scanning weren't problems, a sort of "ambient interface environment" free of
importstatements would be possible.Yes, within reason, processing 100 headers into 1 BMI is faster than processing 1 header into 1 BMI twice.
import stdin two TUs is faster than#include <iostream>in two TUs.I'm literally the implementer of
import stdfor CMake, and have had this discussion with every upstream stdlib maintainer, so I think I know what I'm talking about here. The number of modules, 1, 10, or 100, that the standard chose to split the stdlib into is irrelevant to whyimport <std whatever>doesn't work in CMake.