CODEWITHSUNDEEP
c++c++20
Timo
Timo

Reputation: 9835

Do modules finally allow readable names in the standard library implementation?

With the introduction of modules in C++20 we finally have a tool to encapsulate code from one another. Especially because the preprocessor macros don't leak to other modules.

Afaik, the reserved names (like _Tp, _First, __last) were introduced to avoid macros messing up the standard library implementation, for example:

#define first Yabba Dabba Doo

template <typename RanIt>
std::sort(RanIt first, RanIt last);

I'm aware that the standard library won't be modularized for C++20, but probably for C++2x. Would a modularized implementation of the standard library finally allow normal, readable names for things like parameters and internal types (without running into UB or compiler errors) or is there some other restriction blocking this?

Upvotes: 4

Views: 136

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 473916

Yes, a standard library implementation specifically for a module-based interface would be isolated from user-defined macros and therefore could use "normal" names. Well, maybe; I'll cover that possibility at the end.

Regardless, I would not expect this to happen in the immediate future, even after a hypothetical C++23 with libraries in modules.

The reason being that you would still need to be able to #include the standard headers, even in module-based code. So those headers need to still be available. And while a compiler could legally convert #include <vector> directly into import std.vector (assuming both define the same things), it may be a backwards compatibility break for users of that platform who might add some #defines before the #include. There would be no similar expectations if you import std.vector.

Given that you'll still need the standard library headers lying around, it's highly unlikely that any implementation will want to support 2 copies of standard library code: one for headers and one for modules. It's must easier to define the standard library modules by #include the appropriate headers and export specific symbols from them.

So the base code would still be written as headers and therefore would still have to assume that users could have any set of #defines before the #include.

There is one issue that could make this impossible. Modules still have to deal with external defines, not from user code before a #include, but from compiler switches. People will use such switches to parameterize their modules, and that's fine. However, such switches are outside of the domain of the standard, so it's not clear whether implementations would have to code defensively against them or not.

Upvotes: 3

Related Questions