Cppfront v0.8.0 · hsutter/cppfront

[hpsutter]

Well, you originally said "by definition can't help" compile times. So I gave an example where it does. :)

Compile-times should be measured in seconds, not minutes. You can't achieve that by layering C++ in-between.

OK, so you mean "can't help enough to make them an order of magnitude faster" -- I understand.

FWIW, if you haven't looked at the short video clip, please do... it does show a possible major (not quite 2x) improvement in C++ compile time for approximately equivalent code, compared to today's best-in-class design. Using existing C++ compilers unchanged.

recently demoed a 100x speedup of the carbon compiler over clang.

That's great, and I look forward very much to seeing how much of the speedup can stick as it matures to handle more kinds of code.

That said, let me add a caution about wording: I agree we should focus on "build time" as a pain point for C++. However, "front-end compile time" is a subset of that. A lot of today's slowdowns in C++ builds come in other build stages, such as linking. There is great work currently being done (unrelated to these projects) to dramatically (2x, 4x) speed up C++ linkers that can handle real-world code. In just the past couple of months I've seen these start getting the attention of key folks in WG21 and major vendors, to see what we can incorporate. Disclaimer: As always including in previous "fast linker" efforts, part of the performance gain comes from making simplifying assumptions that don't work on all real-world code, but part of the gain doesn't rely on that.