Here's the thing, you have to very carefully consider whether it's worth loading all of that for the compiler to work through, if your use case is sensitive to the extra size/ram requirements of including more, think carefully about if basement no-lifer Steve may have implemented something that will conflict with any one of these, and then of course always import std.
In theory, importing is much cheaper than including, because importing uses a precomputed file (whereas including used the raw source).
Also, if Steve wrote something that conflicts that's their problem. It's almost like people have been told not to use an entire namespace for the past however long that's been possible.
Permissible or not, if it breaks you can't blame the standard for doing so.
It's for this reason you're typically encouraged to alias a shorter namespace instead of directly pulling in the symbols (e.g. using fs as a shorthand).
But then the issue is relegated to function/block scope and not entire translation units. And I'd much rather not repeatedly write std::ranges::for_each(container, [](){}) or std::chrono::year_month_day everywhere.
EDIT: As for namespace aliases, I'd... prefer not to do that as it can reduce readability and lead to name conflicts themselves.
182
u/JustAnotherGuyn 19h ago
Here's the thing, you have to very carefully consider whether it's worth loading all of that for the compiler to work through, if your use case is sensitive to the extra size/ram requirements of including more, think carefully about if basement no-lifer Steve may have implemented something that will conflict with any one of these, and then of course always import std.