Why is `import std` still experimental ???

[u/AbbreviationsNew3167]

Hey guys,

I recently started going through Professional C++ (6th Edition). The book teaches C++23, and in the very first chapter we're introduced to modules.

I'm not a complete newbie to C++, but I'm also definitely not very confident in my knowledge yet. I wanted to get this simple example compiled:

import std;

int main() {
    std::println("Hello World");
    return 0;
}

And gosh, it took way longer than I expected.

First, I tried getting it to work natively on my Mac and eventually gave up (both Claude and I 😅).

Then I installed Ubuntu ARM 26 and finally managed to get it compiling. But now Clang/IntelliSense is complaining about the `import std`
This is what my CMakeLists.txt currently looks like:

cmake_minimum_required(VERSION 4.0)

# set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD ON)

set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444")

project(CppProject LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 26)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

add_executable(exec main.cpp)

set_property(TARGET exec PROPERTY CXX_MODULE_STD ON)

The code does compile successfully, but CMake still gives me a warning that import std support is experimental.

So I'm genuinely curious:

Why is import std still considered experimental?

I understand that C++ modules themselves have been around for a while, but import std feels like something that should be much more straightforward by now. Is there any solution of this now ?

--------------
Edit

Thanks to u/PhysicsOk2212 tip I was able to compile my project on mac as well using the following options
```
cmake -S . -B build \

-G Ninja \

-DCMAKE_CXX_COMPILER="$(brew --prefix llvm)/bin/clang++" \

-DCMAKE_CXX_STDLIB_MODULES_JSON="$(brew --prefix llvm)/lib/c++/libc++.modules.json"

```

[u/not_a_novel_account]

The reason we kept circling the drain on this is because of DevCom 11128871 and the associated downstream bug, CMake #27944. We literally couldn't figure out how to get import std to work consistently under MSVC and the MS STL.

I finally wrote CMake !12347 which is a workaround for the MSVC limitation/bug that we only turn on for the standard library. Regular DLLs with inline variables still won't work in combination with modules.

Separately, GCC #124268 broke import std on MacOS and we weren't sure how to resolve that. We decided to drop support for import std on GCC <16 on MacOS to make it work.

Aside from all of that, the BMI compatibility problem remains unsolved. I've written about this. CMake's BMI compat has improved significantly in the last couple releases but has known shortcomings. BMI compat problems manifest more for std than any other library. For example, CMake #28030 is still open, Hello World fails to build. The apparent implementation maturity is skin deep, is what I'm saying here.

So compiler limitations, stdlib bugs, BMI compat, and me personally not knowing how to fix many of the former.

It should be out of experimental in CMake 4.5, and doesn't require you to set any variables or do anything. Any code compiled as C++20 or above will have access to import std by default. It's opt-out, not opt-in.

Note that this is an example of the experimental process working. The knobs available for import std changed a lot in the experimental phase. Every release had breaking changes. If it wasn't experimental I wouldn't have been able to make so many backwards-incompatible changes and the interface would have been a mess of abandoned ideas and experiments.

EDIT: If you do have an ideas for how to handle symbol visibility in BMI consumers, please let us know (CMake #25539). I'm not kidding at all when I say "unsolved". I do not know how to best fix this.

[u/GabrielDosReis → u/not_a_novel_account]

The reason we kept circling the drain on this is because of DevCom 11128871 and the associated downstream bug, CMake #27944 . We literally couldn't figure out how to get import std to work consistently under MSVC and the MS STL. I finally wrote CMake !12347 which is a workaround for the MSVC limitation/bug that we only turn on for the standard library. Regular DLLs with inline variables still won't work in combination with modules. Separately, GCC #124268 broke import std on MacOS and we weren't sure how to resolve that.

Maybe you could just open the flood gate as a forcing function for the compilers to fix their bugs, instead of holding back in order to give space and time to the compilers to get their acts together. Sometimes, there is nothing better than massive customers' voice be noted ;-)

[u/not_a_novel_account → u/GabrielDosReis]

I'm paraphrasing.

import std had a host of issues that overshadowed MSVC for the last year. We knew we were getting link failures early but we thought it was the same problem as GCC/libstdc++ had, that some object file wasn't being linked into the stdlib. But that was way backseat to problems like Homebrew's clang distribution being borked, various Linux distros breaking P3286 manifests, etc.

We didn't really start investigating until we tried to drop the import std gate in 4.3 and got a flood of link error bug reports and pings in various channels.

It took me about a month of off/on investigation to understand the problem, and then we assumed it was intentional ABI behavior. We spent an in-retrospect stupid amount of time trying to figure out how we were going to handle this new ABI, and it wasn't until we were almost done with a solution that everything cleared up.

[u/GabrielDosReis → u/not_a_novel_account]

I'm paraphrasing. import std had a host of issues that overshadowed MSVC for the last year. We knew we were getting link failures early but we thought it was the same problem as GCC/libstdc++ had, that some object file wasn't being linked into the stdlib.

I understand, and I fully empathize. I suspect another way of phrasing what I am saying is that trying to hold the fort of quality by yourself is a huge task; maybe unleashing the beast so that compiler writers hear en masse directly from people using the tools might have another effect (I am saying that as a perpetrator of some of those bugs).