Definition-Checked Generics, Part 1: The Why & How - Chandler Carruth, Josh Levenberg, Richard Smith

---

Definition-Checked Generics (Part 1): The Why and How - Chandler Carruth, Josh Levenberg, Richard Smith - CppNow 2023
---

This two-part talk explores what fully definition-checked generic programming is, like what was tried with C++0x concepts, how it compares to C++20 templates and concepts, and what advantages checked generics provide.

In the first session, we will work through a series of examples to understand how C++20 concepts work and how they struggle to provide the fundamental benefits of definition checking. We will examine how C++0x concepts, Swift, Rust, and Carbon achieve these benefits and the core differences between their approaches. We then dig into how this form of generic programming provides a better foundation across many aspects of the language compared to C++, and our exploration of this space in Carbon.

In the second session, we dive more deeply into the most challenging aspects of building a compelling definition-checked generics system into C++ or a C++-like language based on our work on Carbon. With each of these problem areas, we again survey existing approaches from C++, Swift, and Rust. We will then show some limitations and challenges with these approaches, such as undecidability or non-termination, and our proposed approach in Carbon.
---

Chandler Carruth

Chandler Carruth is the technical lead for Google's programming languages and software foundations. He has worked extensively on the C++ programming language and the Clang and LLVM compiler infrastructure. Previously, he worked on several pieces of Google's distributed build system and made guest appearances helping maintain a few core C++ libraries across Google's codebase. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. When not hammering away on a weirdly shaped keyboard, he enjoys sushi, fine dining, brown spirits, and everything about wine.

Josh Levenberg

Josh Levenberg is on the Carbon Language team at Google, driving large parts of the language design across its type system. He has worked on a wide range of C++ software over the past 30 years including TensorFlow and MapReduce. Prior to working at Google, he worked in the video game industry, and has a Ph.D. in Math. When not building large, complex C++ software systems he both juggles and practices ballroom dancing. He also has a surprising distinction of having an anime convention named after him (JoshCon).

Richard Smith

Richard is a professional C++ language lawyer at Google and one of the three leads of the Carbon language project. He has worked in great depth on the C++ core language, has authored over a hundred C++ committee papers, and was the editor for the C++17 and C++20 standards. Until recently, he was the lead developer of the Clang compiler. When not working on the guts of programming languages, he likes to play pool, and to annoy his cats with mediocre piano performances.
---

Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---

---

CppNow 2024
---

#boost #cpp #cppprogramming

[Elite]

Carbon gets so many things just right. I hope this also extends to language build in unit tests and "language as build infrastructure" like Zig.

[digama]

42:08 Re: Rust, "Specialization desired, but hard to land due to legacy": it's more like "specialization desired but hard to land due to unsoundness". As is well-known Rust cares a lot about memory safety, and there are known soundness bugs when using specialization on lifetime parameters. There are some ideas for how to fix this but some of those ideas also turned out to be unsound so I think it's just in a holding pattern now.

[Lircking]

Super epic. I will though say, that actually trying to use "T:! MulWith(f64)" in rust and trying to write some generic code where a bunch of generic types have to be multiplied, added, and moded
gets VERY messy in the types. It's mathematically correct, but it's also hard to read if you are trying to do something more complicated than one multiplication.
Don't know a good solution though. Duck typing is pretty bad. Maybe the compiler can tell you what interfaces your types should be implementing?

[isitanos]

ImplicitAs is a very elegant and safe solution to implicit conversion.

[avi]

1:17:00 shouldn't it be:
ImplicitAs(.Result)
instead of
ImplicitAs(.Self)
?

[dmitriidemenev]

41:42 That is not exactly correct. Lifetimes also can be generic parameters.

[androth]

nice to see one mainstream language competing to become a bigger hot mess than the next.