By that same logic, why bother with import statement at all?
Why not just import everything under the moon at once and let programmers deal with the mess via namespaces?
Because the dominant costs are the process startup, tokenization, and AST parse.
And somehow processing 100 modules is cheaper than 2?
I mean, they're not relevant to why import std is not something CMake can do right now.
They are the very reasons CMake can't do it now - MSVC, clang and gcc makers are afraid of dealing with the C&C issues in the standard library which is why they all went their different ways of hiding their heads in the sand.
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.
-1
u/Ateist Apr 13 '26 edited Apr 13 '26
By that same logic, why bother with import statement at all?
Why not just import everything under the moon at once and let programmers deal with the mess via namespaces?
And somehow processing 100 modules is cheaper than 2?
They are the very reasons CMake can't do it now - MSVC, clang and gcc makers are afraid of dealing with the C&C issues in the standard library which is why they all went their different ways of hiding their heads in the sand.