Definition-Checked Generics, Part 1: The Why & How - Chandler Carruth, Josh Levenberg, Richard Smith
Vložit
- čas přidán 14. 05. 2024
- www.cppnow.org
/ cppnow
---
Definition-Checked Generics (Part 1): The Why and How - Chandler Carruth, Josh Levenberg, Richard Smith - CppNow 2023
Slides: github.com/boostcon
---
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
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
CZcams Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org
/ cppnow
---
#boost #cpp #cppprogramming - Věda a technologie
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.
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.
My understanding, but to be fair it's limited as this is really Richard and Josh's area, is that some of what leads to these things being unsound and hard to fix is the legacy. Without the legacy, some solutions to the soundness challenges might be available that would simplify landing specialization. So it's somewhat both?
@@ChandlerCarruth I think there are definitely forward compatibility hazards with actually rolling out specialization, but based on a basic test it seems the issue with unfolding associated types is handled correctly. More precisely, here's an example showing how type projections fail to reduce when you use specialization:
#![feature(specialization)]
trait Foo { type X: Default; }
impl Foo for T { default type X = u8; }
impl Foo for u16 { type X = u16; }
fn foo() -> u8 { ::X::default() }
The key is the "default type", which enables specialization on that type. With it, foo() fails to compile because "::X" is not normalized to "u8", and without it, foo() compiles but the "impl Foo for u16" fails to compile because you aren't allowed to specialize it.
So the legacy issue is that adding "default type" is a breaking change and likely can't be done for any traits from the standard library, but this doesn't prevent stabilizing the specialization feature itself, it only blocks it from being *used* where legacy code is an issue. AFAIK the real reason the specialization feature itself is blocked is because of the soundness issues.
@@ChandlerCarruth I don't think the word 'legacy' applies here. Sure, there are existing implementations in the compiler that take some time to change, but there isn't any code out in the wild using specialization that you need to keep compiling, which would make it unfeasible to make those changes.
@@digama0 When I researched this, I found these blog posts stating that they had a solution to the soundness concerns with specialization: smallcultfollowing.com/babysteps/blog/2018/02/09/maximally-minimal-specialization-always-applicable-impls/ and aturon.github.io/tech/2018/04/05/sound-specialization/
ImplicitAs is a very elegant and safe solution to implicit conversion.
1:17:00 shouldn't it be:
ImplicitAs(.Result)
instead of
ImplicitAs(.Self)
?
So, `Result` isn't yet in scope -- we're still describing the constrain on what it is. So we have an injected way of referencing it that is currently spelled `.Self`. The `.` is used in the where clause to reference a member of the thing currently being constrained -- the type that will *eventually* be bound to `Result`, but hasn't yet been. So `.T` would be equivalent to `Result.T`. Which is where `.Self` comes from -- `Result.Self` == `Result`.
Still, this is a source of some frustration because the syntax is subtle, especially in this context where there is a *different* meaning for `Self` and `.Self`. It can result in amazingly confusing things like `where .Self == Self`. But so far, we've not come up with a better syntax for this.
41:42 That is not exactly correct. Lifetimes also can be generic parameters.
nice to see one mainstream language competing to become a bigger hot mess than the next.
Why are they reinventing rust?
Rust stole plenty of ideas from other languages.
@@sirhenrystalwart8303 Yeah, that's largely how language design works as I understand it.
It's not quite Rust. There are many distinctions:
While the interface generic system looks very much like Rust's, to me this one seems to be much more powerful. Since there is no worry about "soundness" or "lifetimes" we get a much more powerful tool here.
The language is not focused as much on checking borrows and assuring that nothing dangles - it is an actual successor to C++, without the baggage, with relatively "sane" defaults, grammar, generics, "concepts", conversions - but keeping all the unsafety and danger of dangling reference, lifetimes that can end before the views to the objects, iterators etc. It results in a much more powerful language and abstractions, that are not possible (or at least not viable) in "safe" rust.
And mostly, Carbon is supposed to be a successor language in codebases that can't afford switching to Rust and are too big to move them, even module by module. Using Carbon is easier here - what it promises is seamless interoperability with C++, NOT with C as Rust does. Wrapping things in C APIs to inter-operate with Rust is a major pain if you want to migrate a big codebase. This glue layer is temporary. It's another point of failure, another thing to maintain. It can be hard to get right - if you want to keep "soundness" of Rust program and not trigger C++ UB by "safe" Rust code. With Carbon - you don't have any of these worries.
Because Rust doesn’t work for their very real use case. There are billions of lines of critical, performance sensitive code in codebases that will never be converted to Rust. The Carbon language README literally says “use Rust if you can,” and Carbon is built to safely maintain and add new features to existing C++ codebases that will never be migrated.
If you’re starting a new project, and are not a C++ developer, this is not relevant to you. Use Rust.