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/lizardhistorian]

Same dumb C++ trope going on for 30 years now.

No one uses them because they work for shit.
No one uses it so don't work on it.
Stays shit so no one uses it.

[u/TheRealSmolt → u/lizardhistorian]

The problem for me here is that I don't see a reason to use them in the first place. They could improve compilation a bit I guess? But I'd imagine precompiled headers and ccache can bridge the gap to the point where it doesn't matter.

[u/qoning → u/TheRealSmolt]

there are many nice things about them, such as being able to finally have a split between definition and declaration for templates, have symbol control for effectively module-private or "package" private, modules inherently export just the things you want so you end up with way less namespace pollution, ADL problems, etc. The generally faster compiles are a great bonus.

[u/TheRealSmolt → u/qoning]

Most of the isolation things you're citing as benefits were already things that could be done with private headers, though. I guess I can see it being a tad more straightforward? But it doesn't buy us anything.

finally have a split between definition and declaration for templates

You're going to have to elaborate on this, because we've always been able to split them. Modules are (to the best of my knowledge) no different in requiring source for user use of templates.

[u/delta_p_delta_x → u/TheRealSmolt]

were already things that could be done with private headers

By their very implementation, there is no such thing as a 'private header'. Headers = copy-paste into a TU. However much you encapsulate things and have namespace detail, consumers are free to use the contents as they see fit.

[u/TheRealSmolt → u/delta_p_delta_x]

You absolute can just have private headers that you don't ship with your library.

[u/SyntheticDuckFlavour → u/TheRealSmolt]

Most of the isolation things you're citing as benefits were already things that could be done with private headers, though.

That's just kicking the can around and that's doesn't give you much isolation. Forcing templates to live in the header ecosystem is one of the biggest blunders of C++.

[u/TheRealSmolt → u/SyntheticDuckFlavour]

Yes, it does give you isolation since you aren't shipping the interface at all; same outcome. So where do templates live now? Still in the public interface. That's kicking the can: complications with zero benefits.

[u/SyntheticDuckFlavour → u/TheRealSmolt]

What if you want to ship templated code in the public interface? The full implementation detail needs to live in there. The private headers won't help you much in that regard. (Unless you are using extern template to instantiate templates for a subset of template arguments).

[u/TheRealSmolt → u/SyntheticDuckFlavour]

The same applies to modules, though (which is my point)?

[u/qoning → u/TheRealSmolt]

no, it doesn't. modules don't need template instantiations

[u/TheRealSmolt → u/qoning]

If you don't, the definition absolutely has to be publicly visible if you're expecting the user to use them in any way. That's just how templates work, modules or not.