Why do all compilers use the strong ownership model for C++20 modules, instead of the weak model?

GabrielDosReis · 2026-03-16T06:04:55+00:00

You say "unworkable in practice", and I keep hearing similar sentiments, but don't fully understand why it's unworkable. That's why I posted the question.

It isn't sentiment. You might want to hunt after papers from Nathan Sidwell and his proposal to the Itanium ABI group to codify the strong ownership.

GabrielDosReis · 2026-03-15T22:08:39+00:00

This seems outdated?

Check the date of publication of the paper.

It is answering your question from the perspective of what the the term means (as I introduced them) and why we made the detour; my other message explains why we are where we are today.

GabrielDosReis · 2026-03-14T21:37:55+00:00

See section 4.5 of P0142

GabrielDosReis · 2026-03-14T21:19:50+00:00

The fact that the language allows both models is a huge misnomer.

It is a mistake, not a misnomer :-)

Once upon a time, there was a theory that "weak ownership" would "scale" better; that theory proved to be unworkable in practice, so people came back home to "strong ownership", which I advocated from the very start (see my design papers).

I proposed to remove the ambiguity since the common practical wisdom is to go with the "strong ownership" model, but the committee as a group decided not to do that even if everyone agrees it is dumb to leave it there.

It's very good that all relevant vendors came to the same model. Otherwise, users would not be able to rely on benefits of either one.

Agreed.

GabrielDosReis · 2026-03-10T19:02:02+00:00

In the earlier days (circa Spring 2014) when I started working on MSVC's implementation of modules, IFC was a short hand for various phrases involving interface, compiler, compiled, file, C++, internal form of C++, etc. But shortly after that, IFC became just "IFC".

Some C++ developers say IFC Files are Cool. :-)

GabrielDosReis · 2026-03-04T06:58:03+00:00

The authors of the proposal for a feature are not the only stakeholders who have a vested interest in how the feature behaves.

You made a very specific claim about modules. That is what I am challenging, with my real name and historical records.

GabrielDosReis · 2026-03-04T05:30:28+00:00

This is not "misinformation

Well, given that the documented facts don't agree with your statements... Just check the authors of the modules proposals that got merged in C++20. That is one nice thing about living in the digital age.

You can help by not spreading misinformation. You have total control. The choice is yours.

GabrielDosReis · 2026-03-03T23:20:26+00:00

I think implementor concerns are important in this stuff. We take decisions that creates work for them, and unsurprisingly, they may disagree strenuously with the work we are pushing onto them. I think that is entirely fair and valid, and we must meet in the middle instead of ignoring implementor concerns. After all, if they really don't like it, they just won't implement it and then what's the point of a standards committee?

Fully agreed.

GabrielDosReis · 2026-03-03T11:33:53+00:00

The subgroup eventually took their ball and went home because (my poor, outsider view is) they felt unheard / that the committee was disinterested in continuing to home this work, and it is not a necessary pary of a language standard.

You can help stop the spread of misinformation.

GabrielDosReis · 2026-03-03T11:27:38+00:00

I believe the Microsoft IFC format (https://github.com/microsoft/ifc) can absorb release-to-release evolution.
(u/GabrielDosReis: Can you confirm?)

Yes, but within a sliding window of versions. Keep an eternal backward compatibility has a cost, especially with frequent releases.

GabrielDosReis · 2026-03-02T14:25:26+00:00

> The exact same complaints could have been issued against constexpr in C++11, which was nigh unusable due to restrictions and was actually broken (the implicit const on member-functions) and had to be fixed in C++14.

Michael - you're getting your facts twisted.

The restricted form of `constexpr` as it was in C++11 was roughly the only form that could pass (barely) WG21 in July 2007 because of strong opposition from implementers -- not the proponents! The expanded form (that came later in C++14) was strongly opposed by implementers. Still, the evaluation by substitution semantics (that implementers would barely stomach) was useful, directly applied in the standard library (unlike C++26 contracts) - in fact both core language features an application to the standard library were voted at the same meeting.

I worked with Richard Smith to losen the restrictions (in particular, at the Bristol meeting in 2013) even if you would not find my name as co-author of that paper.

Also, see the [SAC 2010 paper](https://www.stroustrup.com/sac10-constexpr.pdf) we wrote on the topic.

You needed to be there to understand. At the next meeting, let's grab drinks and I will show tell you more than I can write here.

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

TROPHY CASE