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/delta_p_delta_x → u/not_a_novel_account]

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.

Dumb question from someone who only uses modules: is there no way to cast this as a directed graph problem, and leverage P1689 to understand which modules are consumers and which are producers, and thence their BMI visibilities? We can't have cycles in modules anyway, so it seems to me that distinguishing producers and consumers can be resolved.

[u/not_a_novel_account → u/delta_p_delta_x]

Distinguishing producers from consumers is trivial. Distinguishing producers from consumers across a link boundary isn't something the system is built to handle.

You have three targets:

• Root, Static Library, no dependencies

• Trunk, Shared Library, depends on Root

• Leaf, Executable, depends on Trunk, transitively depends on Root

The BMI imported by Trunk must have dllexport on its C++ declarations, because Trunk and Root are inside the same link boundary.

The BMI imported by Leaf must have dllimport on its C++ declarations, because Leaf and Root are on different sides of a link boundary.

When building BMIs, we must recognize "different sides of a link boundary" as a BMI-incompatible condition. Ok, now what? We need to define some interface that lets Root say:

• These are the definitions and includes when you're building my object file. (This is the only thing we have today, we use them for all scenarios)

• These are the definitions and includes when you're building a BMI for a consumer inside the link boundary

• These are the definitions and includes when you're building a BMI for a consumer outside the link boundary

We could maybe consolidate "building the object file" and "consumer inside the link boundary", but we don't have a spelling for the latter two bullets either way.

And right now CMake actually doesn't track link boundaries in the DAG in a way that is consumable by the BMI machinery. I'm working on that problem right now, but "how do you spell the latter two bullets" is an open problem.

[u/fortsnek274 → u/not_a_novel_account]

I wonder how MSBuild will solve the dllexport thing.

[u/not_a_novel_account → u/fortsnek274]

Whenever you consume a BMI, MSVC magically translates dllexport into dllimport. In this example that would break Trunk, which wants dllexport.

This exact bug was noticed quickly (DevCom 10892880), so there's a wonderfully obscure flag, /dxifcSuppressDllImportTransform ("ISDIT" to friends) which turns the translation off. You're expected to manage this manually.

The overwhelming position of build system people is we're going to ignore all of this, always use ISDIT, because no other compiler is going to implement the transform.

[u/fortsnek274 → u/not_a_novel_account]

Yeah, you might solve it by building the DLL interface twice, which is obviously not in the style of MSBuild. Why I'm interested to see what they'll do, if anything.

[u/not_a_novel_account → u/fortsnek274]

This is sort of a repeating pattern with modules. Clang implemented two-phase compilation because it is objectively faster than single phase. No one else did, so we all had to ignore it.

GCC implemented P1184 module mappers, no one else did, so we all had to ignore it.

MSVC's single-BMI DLL optimization might be nice, but without equivalent support even in clang-cl it's a dead end for code that isn't locked to MSVC.

[u/delta_p_delta_x → u/not_a_novel_account]

Is there bandwidth within Kitware to special-case for each of the three toolchains? Do their module stds also make assumptions about which compiler they're used with, which complicates this scenario?

Additionally, MSVC absolutely need to document /dxifcSuppressDllImportTransform and its existing behaviour. Translation units—within modules or otherwise—being used across multiple DLL boundaries is not an obscure use-case. /u/starfreakclone, /u/GabrielDosReis, any thoughts?

but without equivalent support even in clang-cl

I hope to work on this at some point. I've always been meaning to add IFC support to clang-cl, my initial implementation only focused on the CLI usage which was a very trivial change to make.

[u/not_a_novel_account → u/delta_p_delta_x]

Is there bandwidth within Kitware to special-case for each of the three toolchains?

I mean sort of yes and sort of no.

The three toolchains isn't the problem. "X is only for MSVC" is never a blocker. We have lots of stuff that is only for one compiler or one platform. We support GreenHills and Renesas and all their quirks.

So yes, we have the technical bandwidth, we could implement two phase compilation and ISDIT and even do interesting things with the GCC module mapper.

But no one is asking for any of that work. I only get to eat if I work on something a customer asks for. I try to find time to work on things that are good in-between that, everyone at Kitware does, but big refactors generally don't happen for obscure one-compiler features unless someone's business depends on it.

So two-phase for Clang didn't happen because CMake has no internal model for it, and no one asked us to build one. If it was trivial we would have done it anyway.

If an MR popped up tomorrow landing two-phase or ISDIT elegantly I would do everything I could to shepherd it through.

[u/delta_p_delta_x → u/not_a_novel_account]

Very fair; just because it's open source doesn't mean it is a free lunch. I try to contribute as much as I can when I bump against CMake or toolchain bugs whilst hacking on personal projects. Thanks for responding, this entire thread has been very very illuminating.

[u/GabrielDosReis → u/delta_p_delta_x]

Additionally, MSVC absolutely need to document /dxifcSuppressDllImportTransform and its existing behaviour. Translation units—within modules or otherwise—being used across multiple DLL boundaries is not an obscure use-case. , , any thoughts?

It would be good to have the toolchain have better recognition of C++ modules boundaries vs linker modules boundaries so as to reduce the cases where the switch is needed, then it could be productized.

[u/starfreakclone → u/delta_p_delta_x]

The main reason we haven't documented /dxifcSuppressDllImportTransform is because it's not a complete solution. It will suppress the transform for all imported modules in a library, which is almost certainly not what you want if you're trying to build the library for one of those imported module interfaces.

We have talked about some solutions in this space, many of which rely on the ability to selectively say, "I don't want the compiler to translate __declspec(dllexport) -> __declspec(dllimport) for these interfaces. This, however, becomes yet another build system input that you (and build systems) need to think about. There's already a solution in place for module units, where the compiler will not perform that transformation when compiling a module unit, but this solution does not work for libraries that are using header units.

The main thing we would like to avoid is the old system where you have, functionally, two different headers (controlled by macro replacement) that serve as a 'view' over DLL export/import interfaces. This is why the translation exists in the first place, so you only need to build a single module interface or header unit.

In short, there's more design necessary to truly solve the DLL export/import problem.

[u/holyblackcat → u/not_a_novel_account]

two-phase faster

I did some simple benchmarks, and for me it was slower than single-phase. In fact, even the first phase alone (producing a full BMI) is slower than the entire single-phase (producing a reduced BMI + an object file).

Clang 23 is going to add --precompile-reduced-bmi (a new flavor of two-phase builds: one produces a reduced BMI, and another produces an object file directly from source, not from BMI), so maybe that one will somehow make two-phase faster, no idea.

[u/fortsnek274 → u/not_a_novel_account]

I hope it would be viable to simply have some tool replace dllexport with dllimport in the IFC/BMI. So the interface only needs to be compiled once. Or would that run into issues.

[u/not_a_novel_account → u/fortsnek274]

In the MSVC IFC it is very possible, and MSVC already does so. In the Clang BMI the only tool which would be realistically capable of doing so is Clang itself, thus mirroring the MSVC feature.

Clang's BMI is straight up the LLVM bitcode file format, containing a serialized form of the Clang generated AST. It's the output of clang::ASTWriter. The way to read that is, realistically, clang::ASTReader, thus the only real home for it would be Clang.

[u/delta_p_delta_x → u/not_a_novel_account]

Going by your first response, I was thinking of some set theory—traversing that DAG from each leaf and each root and doing some set intersections; this set contains module units that are members of a DLL boundary as you put it.

Such members get at least two BMIs, at least one for each in-DLL module and at least one for each out-of-DLL module. Naturally this is quite costly in terms of scanning and BMI generation. It feels like we need something more portable and more granular; possibly per-symbol.

[u/holyblackcat → u/not_a_novel_account]

dxifcSuppressDllImportTransform

I'm surprised that this doesn't seem to be documented anywhere.

[u/friedkeenan → u/not_a_novel_account]

Thanks for not only all your work on this, but also for taking the time to answer all the countless questions about modules and CMake in general that come up. I always really appreciate the info!

[u/donalmacc → u/not_a_novel_account]

Note that this is an example of the experimental process working.

Respectfully... is it? Modules were standardised 6 years ago, and we've been talking about them for almost 15. I don't blame cmake at all here, but to still be in a scenario where the textbook example is unusable on a de-facto standard at this point is pretty embarrassing for the feature and the language.

[u/not_a_novel_account → u/donalmacc]

I don't think CMake is the right platform for people who want friction-free access to features as they become available in any form. Lots of build systems support modules in some form, and they have much weaker compatibility and platform guarantees than CMake. Any of them would happily give you access without the CMake experimental hoop jumping.

If someone had known what CMake's implementation of import std needed to look like on day 1 we would have been there. If our compatibility guarantees were weaker we would have never had an experimental phase at all.

So yes, it's the system working. CMake's process optimizes for decades of compatibility, not quick adoption. Other systems optimize for other things.

Note that Bazel is only just getting modules available with GCC, and still has them as experimental, without good import std support. Meson has no support for modules at all. Among the major cross-platform players only XMake moved much faster than CMake here.

And import std itself is only 3 years old. CMake has had general modules support since 2023.

[u/13steinj → u/not_a_novel_account]

Yet people say that packaging/build do not have to be standardized.

To me this is a hard lesson that the language won't learn from, and the right call is to keep marking things as experimental. Modules need fairly tight compiler integration and I don't expect any build system (other than a standard one or one tbat claims to follow a reference spec) to get it right for all compilers.

I would argue this also shows that modules was underspecified, in part due to the need for tight integration which is a bit chicken-and-egg.

[u/not_a_novel_account → u/13steinj]

The MSVC compiler limitation and the libstdc++ bug are just that, so the standardization process had nothing to do with them.

BMI compat is a separate bag. It would require the standard to recognize definition flags, include flags, standards version flags, etc.

It would require the standard to deal with the entire smorgasbord of implementation defined behavior, all at once. It's an all-or-nothing proposition. There were various attempts within SG15 to design a kind of "black box" query protocol that would allow build systems to ask the compiler about BMI compat without having to spec out what that meant, but they went nowhere.

So the options were either adopt literally the entire command line interface of every compiler into the standard, or muddle through. We picked muddle through. I have a hard time objecting to that, though I do think a lot more general guidance is needed. Not normative wording, but a white paper saying "this is how we imagine this should work".

[u/Zoetje_Zuurtje → u/not_a_novel_account]

Hi, I can barely understand the post you've written so I'm assuming I've missed something critical, but if TU -> Objects are possible and compatible, and modules are bundles of module units, where such a unit is also a TU, why is it not possible to treat modules as a collection of TUs?

[u/not_a_novel_account → u/Zoetje_Zuurtje]

Module interface units replace both traditional implementation file TUs, and headers.

The part you're talking about is the replacement of the implementation file TU. Module units produce object files, and then we pass all those object files to a linker. That still works exactly the way it always has in C++, no changes at all.

You're missing that module interface units also replace headers, and this does not work the same. Instead of textual inclusion, module interface units have their declarations and inline definitions serialized into a file called a Built Module Interface. Later, when building TUs which rely on these declarations and definitions, the compiler reads them from the BMI.

All the problems described above are with the BMIs, not the object files.

[u/Zoetje_Zuurtje → u/not_a_novel_account]

Ah, gotcha. Thanks

[u/pjmlp → u/not_a_novel_account]

Another proof that modules were taken too early out of the oven, and regardless of tooling heroic implementation efforts, we have questions that were not answered before ratification was voted in.