Thanks again to C++ Now for inviting me to speak this year in glorious Aspen, Colorado, USA! It was nice to see many old friends again there and make a few new ones too.
The talk I gave there was just posted on YouTube, you can find it here:
At CppCon 2022, I argued for why we should try to make C++ 10x simpler and safer, and I presented my own incomplete experimental compiler, cppfront. Since then, cppfront has continued progressing: My spring update post covered the addition of types, a reflection API, and metafunctions, and this talk was given a week after that post and shows off those features with discussion and live demos.
This talk also clearly distinguishes between what I call the “Dart plan” and the “TypeScript plan” for aiming at a 10x improvement for an incumbent popular language. Both plans have value, but they have different priorities and therefore choose different constraints… most of all, they either embrace up-front the design constraint of perfect C++ interop compatibility, or they forgo it (forever; as I argue in the talk, it can never be achieved retroactively, except by starting over, because it’s a fundamental up-front constraint). No one else has tried the TypeScript plan for C++ yet, and I see value in trying it, and so that’s the plan I’m following for cppfront.
When people ask me “how is cppfront different from all the other projects trying to improve/replace C++?” my answer is “cppfront is on the TypeScript plan.” All the other past and present projects have been on the Dart plan, which again is a fine plan too, it just has different priorities and tradeoffs particularly around compatibility.
The video description has a topical guide linking to major points in the talk. Here below is a more detailed version of that topical guide… I hope you enjoy the talk!
1:00 Intro and roadmap for the talk
2:28 1. cppfront recap
2:35 – green-field experiments are great; but cppfront is about refreshing C++ itself
3:28 – “when I say compatibility .. I mean I can call any C++ code that exists today … with no shims, no thunks, no overheads, no indirections, no wrapping”
4:05 – can’t take a breaking change to existing code without breaking the world
5:22 – to me, the most impactful release of C++ was C++11, it most changed the way we wrote our code
6:20 – what if we could do C++11 again, but a coordinated set of features to internally evolve C++
6:52 – cppfront is an experiment in progress, still incomplete
7:41 – thanks to 100+ cppfront contributors!
8:00 – summary slide of features demonstrated at CppCon 2022
– safety for C++; goal of 50x fewer CVEs due to type/bounds/lifetime/init safety
– simplicity for C++; goal of 10x less to know
10:00 – 2. cppfront: what’s new
10:05 – (a) 3 smaller new features showing simplicity+safety+efficiency
10:15 – <=> from this work has already been standardized
11:05 – simplicity, safety and efficiency rarely in tension, with the right abstractions
12:55 – chained comparisons: simple, safe (mathematically), efficient (single eval)
15:08 – named loops/break/continue: simple, safe (structured), efficient
16:51 – main’s arguments: simple (std:: always available), safe (bounds/null check by default), efficient (pay only if you ask for main’s parameters)
18:30 – (b) user-defined types
19:20 – explicit `this`
20:20 – defaults: rarely write access-specifiers
21:30 – (recall from CppCon 2022: composable initialization safety with `out` parameters)
23:50 – unified `operator=`: {construct,assign}x{copy,move} is a single function (by default)
25:48 – visual for unified `operator=`
27:28 – walk through example code generation for unified `operator=`
31:35 – virtual/override/final are qualifiers on `this`
35:05 – DEMO: inheritance (GCC this time)
40:43 – easter egg
41:55 – can interleave bases and members, more control over layout and lifetime
43:10 – (c) reflection and type metafunctions
43:10 – recap overview from CppCon 2017
54:23 – DEMO: applying type metafunctions
56:10 – 3. compatibility for C++
56:35 – John Carmack on compatibility in the real world
59:40 – recall: summary of “Bridge to NewThingia” talk
1:02:05 – avoiding an adoption step function requires high fidelity compatibility
1:04:25 – C++ from C, TypeScript from JavaScript, Swift from Objective-C, Roslyn from prior compiler
1:05:45 – emphasizing and dissecting TypeScript’s compatibility story
1:07:55 – Dart: similar goal, but not designed to be compatible, and you’ll never be able to back into compatibility without starting over
1:08:55 – examples of why incompatibility costs a decade:
1:08:57 – – VC++ 6.0 to 10.0 … 12 years
1:10:28 – – Python 2 to 3 … 12 years (Python is C++’s #1 sister language)
1:18:30 – – C99 to C11 … 12 years
1:18:50 – – C++11 basic_string (approved in 2008) to 2019 support on all major platforms … 11 years
1:19:25 – the “lost decade” pattern: lack of seamless compatibility will cost you a decade in adoption
1:20:45 – three “plans”: the “10% plan”, the “Dart plan”, and the “TypeScript plan”
1:21:00 – “10% plan”: incremental evolution-as-usual
1:21:40 – so how do we get a 10x improvement?
1:21:50 – “Dart plan”: designing something new, not worry about compatible interop, competitive
1:23:20 – “TypeScript plan”: designing for something compatible, cooperative
1:25:40 – what it takes to evolve C++ compatibly, which no other effort has tried before
1:28:50 – filling in the blank: ______ for C++
Sutter’s Mill 