Supporting `import std;` in C++20

[StephanTLavavej]

Currently, we block the C++23 Standard Library Modules from being used in C++20 mode. There's no technical reason for this, it's purely a policy choice. Supporting import std; in C++20 mode would be easy (remove the block, add test coverage, it'll take me just a few minutes - at least in the toolset, then we'll need to talk to the build systems), because we don't need anything from the C++23 Core Language here. However, after granting this ability to users, we can never take it back.

Therefore, we're looking for cross-vendor agreement. Next Wednesday (2023-08-16), the MSVC STL maintainers will talk about this at our weekly scheduled meeting and I expect we'll agree that this is a reasonable thing to do. If the libc++ and libstdc++ maintainer teams could discuss this in their own channels and then add comments here saying "The lib<meow>c++ maintainers want to support import std; in C++20 mode", then we can move forward together.

(This equally applies to import std.compat;, of course. It does not apply to any future modules that might be added to C++26 and beyond. Please note that we're not running a user survey here.)

[jwakely]

The libstdc++ maintainers want to support import std; in C++20 mode.

I've noted this at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 too.

[ldionne]

There doesn't seem to be any technical concerns so libc++ will follow as well. We'll document it as an extension on our side around https://libcxx.llvm.org/UsingLibcxx.html#libc-extensions.

[grafikrobot]

Some basic questions:

1. Does this also mean that when C++26, etc, comes along they will also be usable in the C++20 mode?
2. Will all of the std be available, or just the C++20 parts?
3. Will the feature macros indicate C++23 or C++20 for the respective parts when compiling in C++20 mode when importing the C++23 std?

[StephanTLavavej]

1. Does this also mean that when C++26, etc, comes along they will also be usable in the C++20 mode?

No. If C++26 adds std.meow modules, we implementers will need to separately decide whether to support those modules "downlevel" in C++23 and C++20 modes. (This may be technically difficult, if the C++26 Core Language adds module features that the Standard Library begins depending on, for example.)

2. Will all of the std be available, or just the C++20 parts?

Just the C++20 parts (with any LWG issue resolutions and C++23-and-later features that implementers have chosen to backport).

This simply means that in -std=c++20 / /std:c++20 mode, import std; and #include <all_standard_library_headers> provide the same functionality, modulo macros.

3. Will the feature macros indicate C++23 or C++20 for the respective parts when compiling in C++20 mode when importing the C++23 std?

Mu. import std; doesn't provide any macros, including the feature-test macros.

If you're in C++20 mode and import std; followed by (or preceded by) #include <version>, you get C++20 level feature-test macros, which correspond to the machinery you've imported.

Hopefully this all makes sense - the whole reason that the implementers view this as very easy to support is because the Standard mode is mostly orthogonal to the module mechanism (we have all made our codebases conditional on Standard mode, so selectively lighting up just the C++20 parts is trivial regardless of whether it's being done via classic headers or named modules).

[mordante]

What @stl said matches what I intend to do for libc++.

[jwakely]

Does this also mean that when C++26, etc, comes along they will also be usable in the C++20 mode?

Nobody is suggesting that C++23 (e.g. std::expected and std::mdspan) will be usable in C++20 mode. So C++26 (e.g. std::submdspan) won't be usable in C++20 mode either.

[StephanTLavavej]

The MSVC STL maintainers are (unsurprisingly) in favor of this too; I'll work on a PR for our repo. Thanks everyone!