What to Do with C++ Modules?

Rust solves 1 category of problems in a way that is not without its costs and other consequences. That is it. There are projects where this is very important, there are other projects where its virtually useless and the consequences just get in the way. It is not magic. It doesn't make anything actually 'safe'.

I bet there's easily tens of thousands of times more C++ code than Rust code out there.

- GCC switched from C to C++

- CUDA switched from C to C++

But I can understand the decision, and at that time , C++ frontend features and libs were a little bit less horrible.

variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic.

C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use.

Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.

I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born.

C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate.

Everything else is well on its way to be implemented, in one of three forms - core language features (eg: concepts), language features that primarily enable writing more powerful libraries so that you do not have to come up with language features for everything (eg: reflection), and finally tooling support from the compiler as a test bed of what the language could guarantee (lifetime checks and annotations in clang).

Of course Rust is innovating pretty well too, I am very interested in seeing what async/coroutines are going to look like in a few years.

But as it stands, I expect that whatever innovations these languages produce will be picked up by C++ in ~5 years.

These are all highly non-parallel problems. They don't gain much from being parallel, and because Rust imposes 'restrict' semantics on even single threaded code you end up making it much harder to write code in these domains.

This has been my experience with Rust. Shared mutability is safe on a single thread without 'restrict' on all your pointers, and Rust has limited options to opt into shared mutability (with lots of ergonomic caveats).

Don't get me wrong though, I still think Rust is a great tool. It just has tradeoffs.

You’re forced into function-call or jump-table dispatch, which tends to be slower.

The C++ solution would be to start the threads and use an MPSC queue (which, ironically, Rust also has) in order to update the UI.

Rust will eventually stumble upon ergonomics and allow portions of code to be specified as single threaded or embarrassingly parallel, but unfortunately the community evolved horse blinders early on and isn't letting them go any time soon.

C++ has adapted the ‘using’ keyword now to seem fairly similar to alias, but can’t completely subsume macros unfortunately.

This seems incredibly wasteful, but of course still marginal better than just #including code which is the alternative.

D does not require names in global scope to be declared lexically before they are used. C++ only does this for class/struct scopes. For example:

    int bar() { foo(); }
    int foo() { bar(); }

Importantly, no they did not.

They put a boundary on the preprocessor containing preprocessing within the module definition and not the code importing the module.

And that's where a lot of the loss and compatibility problems have come into play. That's why you can't, for example, share a module between builds. Because the ifdefs that built the module in the first place may have changed from one build to the next.

It was good that the committee bound the preprocessor, but they simply didn't go far enough.

C++ is making strides to adding the language features needed to dustbin modules. A lot of the work of consteval can replace a lot of what the preprocessor is doing.

> Because modules supports none of this, that means we can't modulize Windows.h. Or zlib. Or gtest.

And see, that's the issue. Modules do actually support all this. We can in fact modularize windows.h, zlib, or gtest. The issue is the `windows.module` still has to be rebuilt with every application that imports it because those `ifdefs` could evaluate differently depending on what env variables the build system sets before building. The module can't be just a simple AST built once. Maybe once for a project, but that's about it. And that's the rub. Change anything that causes the module to recompile and you spend exactly the same time you'd spend on precompiled headers.

This is the same solution that Apple chose for Swift <-> Objective C interop. I wonder if someone at Apple was inspired by this decision in D!

For the high-end performance-engineered cases that C++ is famously used for, the performance loss may be understated since it actively interferes with standard performance-engineer techniques.

It may have a role in boring utilities and such but those are legacy roles for C++. That might be a good use case! Most new C++ code is used in applications where something like Fil-C would be an unacceptable tradeoff.

Of course, these tools are of interest to the broader C++ community. Thanks for sharing.

I think there is a hefty deal of ignorance in your comment. A standardization process is not pull-based, it's push-based.

If you feel you have a nice idea that has technical legs to stand, you write your idea down and put together a proposal and then get in touch with committee members to present it.

The process is pretty open.

> Certainly more useful than anything else the standards committees have done in the past 10 years.

Do you understand the "standards committee" is comprised of people like you and me, except they got off their rear-end and actually contribute to it? You make it sound like they are a robe-wearing secret society that is secluded from the world.

Seriously, spend a few minutes getting acquainted with the process, what it takes to become a member, and what you need to do to propose something.

I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.

I've been using ccache for years and I never had any problem getting ccache to support template code. Why? Because the concept of templates is ortogonal to compiler caches. It matters nothing, if you understand how compiler caches work. Think about it. You have the source file you are compiling, you have the set of build flags passed to the compiler, and you have the resulting binary.

That's the whole input, and output.

It's irrelevant if the code features templates or not.

Have you checked if the likes of zapcc is fixing a problem that actually doesn't exist?

You used many words just so say "ccache is a build cache".

> it still needs to rebuild the whole translation unit from scratch if a single line in some header changes.

You are using many words to say "ccache rebuilds a translation unit when it changes".

What point were you trying to make?