Interview on CppCast

A few days ago I recorded CppCast episode 357. Thanks to Timur Doumler and Phil Nash for inviting me on their show – and for continuing CppCast, which was so wonderfully founded by Rob Irving and Jason Turner!

This time, we chatted about news in the C++ world, and then about my Cpp2 and cppfront experimental work.

The podcast doesn’t seem to have chapters, but here are a few of my own notes about sections of interest:

00:00 Intro04:30 News: LLVM 16.0.0, “C++ Initialisation” book, new user groups15:45 Start of interview16:08 Why I don’t view Cpp2 as a “successor language”16:25 A transpiler is a compiler (see also: cfront, PyPy, TypeScript, …)17:20 Origins of the Cpp2 project, 2015/1619:00 100% compatibility as a primary goal and design constraint22:00 Avoid divergence, continue in same path C++ is already going22:50 What compatibility means: 100% link compat always on, 100% source compat always available but pay only if you need it24:14 Making the syntax unique in a simple way, start with “name :”28:10 Avoid divergence and still make a major simplification, by letting programmers directly declare their intent30:30 Bringing the pieces to ISO and the community for feedback31:55 What about “epochs”/“editions”? tl;dr: It’s exactly the right question, but I think the right answer is “epoch” (singular)35:42 C++ is popular and will endure no matter what we do; question is can we make it nicer37:05 My personal experiment, and others are now helping38:20 What “safeties” I’m targeting, and what degree of safety, and why formally provable guarantees are nice but neither necessary nor sufficient (I expect this view to be controversial)44:00 The issue is making things 50x (98%) safer, vs. 100% safer, because what does requiring that last 2% actually cost the design in incompatibility / difficulty of use47:05 The zero-overhead principle is non-negotiable, and so is always being able to “open the hood” to take control, otherwise it’s not C++ anymore48:20 Examples: dynamic bounds/null checking is opt-out, now the default but still pay for it only if you use it50:20 Will cppfront support all major compilers and platforms? It already does, any reasonably conforming C++20 compiler (any gcc/clang/msvc since about 2020), and that will continue52:15 Keeping the generated source code very close to the original is a priority53:25 “TypeScript for C++” plan vs. “Dart for C++” plan55:20 TypeScript did what Bjarne’s cfront did: Transpiler that let you always keep your generated JavaScript/C code, so you could drop using the new language anytime if you want with #NoRegrets, risk-free57:20 Shout out to Anders Hejlsberg, IIRC the only human to produce a million-user programming language more than once, and his approach to TypeScript vs. C#59:20 Why generating C++ code isn’t in tension with the goal of compatibility (it’s actually synergistic), and the targeted subset is C++20 (with a workaround only when modules are not yet available on a given compiler)1:00:40 Why C++20 is super important (if constexpr, requires-expressions)1:01:40 Why any C++ evolution/successor language attempt that for now only tries to be compatible with C++17 faces a big hill/disadvantage1:02:40 What’s next for Cpp2 and cppfront1:05:35 Where can people learn more: cppfront repo, CppCon 2022 talk, C++Now talk coming up in a month, then CppCon 2023 in October1:07:28 C++ world is alive and well and thriving, now embracing challenges like safety to keep C++ working well for all of us

In at least one place I said “cppfront” where I meant “cfront”… I think the intent should be clear from context.

Thanks again to everyone who has helped me personally with cppfront through issues and PRs, and to all the good folks who helped the entire C++ world by working hard and creatively through the pandemic and shipping another solid release of C++ in C++23.