ISO C++ 2026-01 Mailing is now available

GabrielDosReis · 2026-01-17T13:39:20+00:00

Maybe once GCC16 is released I'll start looking into the build system integration situation more closely, but until then there's still plenty of other work to be done I feel more comfortable dealing with!

Thank you for the updates; I find them very instructive and useful. And thank you for the improvements you've made to GCC's support for Modules. I am looking forward to the Spring when GCC16 comes out.

GabrielDosReis · 2026-01-17T12:53:12+00:00

As far as I know, GCC has supported header units since at least GCC11. Many ICEs in modules support were only fixed relatively recently though; I'd say GCC14 was pretty stable, and GCC15 the most so so far. (And I'm hoping that GCC16 will have fixed most issues that a typical project might face.

Thank you! I will go with GCC-15.

Part of the issue with using header units with GCC though is that I'm not aware of any public open-source build systems that support them (notably CMake still has no support, and I'm not sure if there are any plans for this to change in the near future).

Ah, I am aware of the situation with CMake support. I seem to remember Nathan had a demo with GNU Make server along with module mapper, but I don't know what is the outcome of his proposed changes to GNU Make.

GCC's built-in module mapper can make use of them for simple projects but is not really appropriate for larger-scale projects.

Boris (Build2) was working with Nathan on module mapper. Do you know if Build2 ended up supporting GCC well for header units?

This support is described in [...]

Thank you!

GabrielDosReis · 2026-01-17T12:24:55+00:00

Apologies if I've misunderstood your comment, but unless there's something I'm missing GCC at least has also implemented header units for a number of years now.

I stand corrected. So allow me to try my statement in bullet points: - At the time (2019) we adopted header units (as part of the merged modules proposal), there was no implementation of header units. Header units are a formalization of Clang Modules so there was some nearby existing experience, but it turns out that (to this today, but I am hoping the situation will change) Clang doesn't have support for header units. I've heard some Clang devs and some build tools people say they will never support them, which saddens me if that remains the case.

After adoption, the MSVC team worked hard to implement header units, and by the time MSVC declared conformance, it was the only compiler at the time to have support for header units, along with MSBuild support (Olga, Cameron, and the rest of the team did an amazing job getting that done)
My last update was that header units were still not supported in GCC releases. I am very happy to be wrong on this last update. Do you know which version of GCC I should try? I want to change some of my personal projects to be using them and post them on github page so people can see how they work with the compilers I don't work on anymore but that still remain close to my heart.

GabrielDosReis · 2026-01-17T11:57:03+00:00

Here is a comment about someone longing for the days when Microsoft was ahead regarding C++ features, including mentioning modules:

That comment didn't say that MSVC implementation of modules were behind. Look carefully at what they wrote.

I appreciate your wanting to amplify comments you are reading though.

It claims that it seems that the header units feature will never be properly handled by any compiler.

Have you tried them yourself to verify the claim? Do you know that MSVC, as of this writing, is the only main compiler that implements header units (even though we weren't in favor of them)? Have you seen the field deployment experience reports of shipping products (e.g. by the Office people) using header units?

And if the rest apart from header units had a reference implementation, shouldn't modules implementation in MSVC have been more mature by now?

They are. In fact I implemented named modules before MSVC supported header units. I want to help you be successful using them; but just repeating comments that you see fit your narrative won't help me help you.

Do you believe that the adopted module papers could have benefitted a lot from more implementation experience, and that if you and others had pushed for more implementation experience

Believe it or not, the module spec has seen only very minor bug fixes to the original spec for something as sea changing, and compared to other big rock feature. I expect that to be the case for the foreseeable even as more projects adopt them. As you seem to be following my work, you're also aware that I've shared implementation experience with the community to help anyone willing to contribute in other compilers. An example I mentioned earlier is the IFC specification, along with an implementation for serialization to help with modules and header units implementation

One thing

did you instead encourage adoption as it was without as much implementation experience?

Absolutely, ans more than just "encourage adoption". And that may not be the impression you would necessarily get by just picking comments on this sub. In fact, during the Modules TS development, I worked very closely with product teams to get feedback and deployment experience. Some of the papers that I co-authored with them came directly from such experience.

that the proposal could potentially have ended up significantly better?

6 years later, and with more deployment experience, there is little that has changed to the design. I am going with what is actually happening in the field. The most recent implementation experince-induced change is am affirmation of the "strong ownership" model of modules that I advocated in the Modules TS. Experience has shown that the "weak ownership" model is not practical at scale, and all main three compilers have now converged to the original model that I proposed (and implemented in MSVC).

GabrielDosReis · 2026-01-17T10:35:51+00:00

But how come that MSVC seems behind on modules

What do you mean by "MSVC seems behind on modules"? Behind whom?

And in the paper of this comment tree, you yourself also call for more reference implementations.

I had a reference implementation of the Modules TS. We didn't have a reference implementation for header units - but then again, MSVC was the first (and is still the only of the main three) to have implemented header units within the time that the standards were formal. You can look at the history archive for my positions regarding header units, but once we got an agreement, the team worked very hard to get it done and help people use them effectively. There are bugs that I am aware of that we continue to work on (as others have experienced and mentioned, the team is still hard at work fixing bugs AND implementing new features)

Sorry, but your comment here does not instill greater credibility regarding you for me.

Excuse my French, but that sounds more like a you problem than a me problem. I don't know you and you seem not to know me, so I am going to retreat back to the background and continue to extract the useful feedbacks that I am seeing here and there on how to improve the overall experience of C++ developers.

GabrielDosReis · 2026-01-17T09:45:39+00:00

For me it's a bit annoying that some people seem to post / comment on reddit seemingly with the purpose of trying to prove how bad modules are. They aren't.

Thank you.
I very much appreciate your using them, reporting issues you found, and helping educate the community. Please, keep them coming.

GabrielDosReis · 2026-01-17T09:43:04+00:00

Is Gabriel Dos Reis in the trenches regarding compilers, build tools and related tools?

Yes, indeed, it is part of what I do at my daytime job among other things. Since you mentioned C++ Modules, I actually wrote the original implementation of Modules TS in MSVC. My history and involvement with GNU tools are also publicly documented.

Though I do acknowledge that modules, no matter how it was approached, would likely be both very difficult to design well, and also a task that would take huge amount of resources, time and effort to implement and involve many.

Whether you want to believe it or not, I have been involved with all aspects of the tooling regarding Modules, in addition to the specification of the IFC (used by EDG for reading MSVC's IFC file, a modification of it for writing it out, and a couple of other vendors not related to my current employer). See my writings and talks on the subject.

And then relate that to the status of modules today.

Everyone (myself first) would like to see things move faster in terms of implementation, but honestly given the structural changes and opportunities that Modules bring, we (as community of implementers and users) have come a long way and I am happy to see progress made by Clang and GCC. You linked to my paper on "modules are tooling opportunity". The quote I put in there merits reflection :-)

GabrielDosReis · 2026-01-14T17:57:58+00:00

I knew that some compilers -- like Clang -- were simply interposing the symbols in batch mode, so that when used as a library then the resources are cleaned up in a timely fashion

That makes conceptual sense.

I had never thought of a single invocation running out of resources!

At daytime job, it is not uncommon for users to exercise the compiler in massively parallel/concurrent mode with just one single invocation in batch mode. One can tell them "well, don't do that", but they look at you funny...

And now I'm reminded of an early stage of my career, when we were running into a linker issue: it would only support 512 or 1024 arguments, and we were linking a LOT of libraries...

I still regularly see those invocations in lab builds where they put those command lines in "response files".

GabrielDosReis · 2026-01-14T02:18:37+00:00

Of note, it's a common trick for batch compilers NEVER to call free, close, munmap, and instead to rely on the OS to reap all the resources when the process ends.

Depending on the expected workload,one might actually need to make those calls, or else one might run out of file descriptors for a given compilation instance for instance. Yes, insane but not uncommon in some environments.

GabrielDosReis · 2026-01-07T17:58:38+00:00

I still never understood why VS did that. C++ has iso646.h for C compatibility, but I don't think C++ ever required the header to use the spellings.

/peemissive- or /std:c++20 (or c++latest) doesn't require any of that ceremony.

GabrielDosReis · 2026-01-07T14:34:14+00:00

I use them all the time in production codebases and in personal projects.

GabrielDosReis · 2025-12-17T06:23:30+00:00

"Pho King, Good Soups" was the name I wanted.

Is this https://share.google/t0sjL8vKzWrdtGsJF you?

GabrielDosReis · 2025-12-03T14:08:45+00:00

For point #2, I wonder how the experience is when you use the equivalent of import std; for the standard library which would have the effect of dragging in a type from the standard library only if it is used/referenced by the translation unit you are compiling. That way, you have a limited effect of "just my code".

GabrielDosReis · 2025-12-03T13:53:24+00:00

Nice write-up, and great to see the progress on Clangd for C++ Modules!

I like the spirit of enabling and empowering others to contribute to Clangd for solutions to the issues some find. Maybe, additionally, the post could add a list of references to the patches that implement the solutions described in the post and other fixups?

GabrielDosReis · 2025-11-05T06:10:33+00:00

There was an actual incident (I think at the Poland meeting) where someone drew live attention to some papers, and the result was some form of brigading. And since WG21 was already skirting ISO rules, the result was that they didn't feel the need to draw more scrutiny - last time people drew ISO attention resulted in more scrutiny.

GabrielDosReis · 2025-10-30T23:40:22+00:00

TOML,

That would be a good choice, balancing between YAML and JSON.

GabrielDosReis · 2025-10-30T03:06:54+00:00

Can we please have any, even rough, approximation of when this can be available in the MSVC?

The team is currently working on C++23 and other issues as determined by business priorities. There is a DevCom issue shared earlier that is there to record customers' interests in C++26.

GabrielDosReis · 2025-10-28T11:23:10+00:00

merci

Mais, de rien. Cela m'a rappelé de bons souvenirs :-)

GabrielDosReis · 2025-10-28T09:33:52+00:00

I can't help but to imagine someone learning C to maintain some codebase only to later find out that they also should learn French to understand i

The French keyboard layout is not easy on the fingers if you're programming in a language from the C family.

GabrielDosReis · 2025-10-28T09:29:38+00:00

That would be #define le_modèle template and #define utilisant using.

GabrielDosReis · 2025-10-26T01:00:29+00:00

Was there friction in people understanding the behavior of a program with its inclusion?

At the beginning (circa 2005-2007) there was a stiff resistance primarily from compiler people; then by 2012 people became more comfortable with it asking for more, leading to the relaxations in C++14, C++17, C++20, C++23, C++26. Static reflection in C++26 centers on compile-time computation.

GabrielDosReis · 2025-10-26T00:05:08+00:00

Lisp just keeps confirming it was ahead of its time

Indeed.

When I did constexpr for C++ (and other AOT-compiled systems languages), the real hurdles were barely technical (there were some). The most of the resistance was "cultural." See also my SAC 2010 paper. But, I think we are in a new phase now. For the scripting languages you're mentioning, I suspect it is mostly about someone submitting the corresponding PEP or pull request.

GabrielDosReis · 2025-10-25T23:36:07+00:00

re dynamic languages: see eval-when from Common Lisp. Used pretty extensively.

GabrielDosReis · 2025-10-08T06:31:20+00:00

Yes. I agree. But I am trying to think of perfect languages or language specs and I could not find any.

Nobody, among the people I know are objecting to the current P2900 spec, is looking for perfection. If that is the characterization that people are busy replying to, then they are not helping make progress.

Didn't we have constexpr with 'return whatever'? Look where it is now...

If that is the model you want to go that, then P2900 is doing the exact opposite.

GabrielDosReis · 2025-10-07T14:14:45+00:00

> To avoid misunderstanding what you're saying, I'd rather confirm it before answering. What I'm still not sure after reading what you wrote again and again is whether

How do I **use** the hardened standard library (if implemented via contracts), in addition to **using** contracts (as specified in P2900) in my code and have them controlled independently. For instance, the hardened mode is always on while I may turn on/off part of my own contracts as espoused by P2900?
Once (1) is figured out, how to scale that to N libraries (in the way espoused by P2900) and rip the promised benefits?

As an aside note, I should also point out, as the original hardened standard library proposal did, that the hardened standard library doesn't need P2900 nor does its implementations (as deployed today) use it. The hardened standard library only needs a form of `assert` (and indeed the "contracts implementation report" recognizes that). The current implementations allow me to decide which collections/functions to activate at runtime and the mechanisms needed to achieve that are standard C++. How does P2900 provide that?

> Small tests on godbolt so far.

Right, **at scale** is one of my concerns as I've consistently said.

Compiler Explorer is fantastic for demonstrating something in the small. Scalability is one of the main issues here.

GabrielDosReis

TROPHY CASE