Algorithms + Data Structures = Programs - Episode 161: 🎄 EOP, Rust, Hylo, C++20/23/26/29 & More with Zach Laine (Holiday Special #4)

Episode Date: December 22, 2023

In this episode, Conor and Bryce our joined by Zach Laine for their fourth Holiday Special!Link to Episode 161 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Zach Laine has been using C++ in industry for 15 years, focusing on data visualization, numeric computing, games, generic programming, and good library design. He finds the process of writing bio blurbs to be a little uncomfortable.Show NotesDate Recorded: 2023-12-18Date Released: 2023-12-22Previous Zach Laine ADSP EpisodesAlgorithms + Data Structures = ProgramsElements of ProgrammingCppCon 2015: Zach Laine “Writing Great Libraries: 89 Easy Steps”Rust Programming LanguageHylo Programming LanguageReflection for C++26 (Paper)C++ Pattern Matching (Paper)Keynote: C++ Horizons - Bryce Adelstein Lelbach - ACCU 2023Cern Photo of BryceExpression template library Boost.YAPLouis Dionne’s boost::hanaC++17 if constexprADSP Episode 150: Is C++ Dying?C++ Ranges-v3C++20 ConceptsGCC + Clang link to ranges::sort of std::listC++ Weekly - Ep 6 Intro To Variadic TemplatesGQL Data ModelThinking, Fast and SlowDanial KahnemanAmos TverskyIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Oh, Bryce is fancy. He wants everyone to know it. As soon as Bryce said that, I was like, here we go. Zach's about to take him down a bit. Stepanov is very good at building a theory, but also remaining pretty close to how computers actually work. You know, Rust took the problem with writing code in C++. Hey, that's enough, baby. I'm sorry, but I mean, I was just answering what you asked me,

and I don't think you should call me babe. A good review of high-level design and a good design of a library are isomorphic in that you want lots of things to be the same about them. If it's possible to do so, you want to make it impossible to use it incorrectly. If that's not possible, you want to make it difficult to use it incorrectly. Ah, damn. Shit's popping. I like how that just doesn't sound like it goes with hosted by Bryce and Connor. Welcome to ADSP the podcast episode 161 recorded on December 18th, 2023. My name is Connor and today with my co-host Bryce, we are joined by Zach Lane for our fourth holiday special, a special episode, our longest yet, all released

in one cut. In today's episode, we talk about a plethora of topics, including the elements of programming, the Rust programming language, the Hylo programming language, C++, 20, 23, 26, 29, all of the upcoming features that people are excited about, and a lot more. We hope you enjoy today's special episode. Should we switch to a different Google? No, this is perfect. Also, should I be recording right now?

Should I be recording right now? Yes, just for the viewer right now, what we are seeing of Connor is we are seeing a black and white image that looks like it's nighttime. And it's flickering at about, I would say, like 80 hertz at least. It is. It's a little terrifying. Yeah, it looks like a horror movie. It really does. It looks like one of these cheap Blumhouse movies like Paranormal Activity or something. It's like the black and white grainy one light source night vision thing.

It's just all creepy. You know, the really bad part here is Connor's reason for why this is happening. Oh, no. I was talking about you, Bryce. Oh, no. Connor's weird, too. Are you also in a working kitchen? He's in an airport lounge.

He's using Linux. And does your laptop have an NVIDIA GPU? It does, yes. Yes, this is entirely our fault. I mean, the thing is, though, and I've just realized that this Wi-Fi quality is not great, so I'm going to be dropping in and out of this call. So I can't slack off today. I've got to carry this recording. Which I can't slack off today. I gotta carry this recording.

Which airport lounge are you in and at which airport? I'm in San Diego in the Aspire Lounge in Terminal 2. I don't know if I've ever been there. Yeah, maybe this was a bad idea in hindsight. Before we informally introduce Zach, should I just... I've turned my camera up. Is that the best option at this point?

I won't be able to keep us... It's super freaky. Alrighty. I mean, this probably all ended up in the episode, so you've just been listening to absolute mayhem and chaos for the first few minutes. But, welcome to episode 161 this is our third i don't even know if it's our i think it's our third holiday special could be our fourth who knows and as promised the returning guest from episodes 117 to 121 inclusive probably the funniest the most entertaining guest we've had of all time zach lane is with us for the holiday special and uh how you doing zach i mean we'll link your previous episodes it's good to

have you back how have you been it's gonna be back yeah i've been i've been good it's um it's it's uh i think that the show is much more um since being on the show, like I had heard several episodes of the show before. But now it's become like a regular thing. Like I listen to it all the time. So I've been keeping up with you guys a lot better than I usually do. If you want to expand your listenership, you just got to get people to come on one at a time. Just a few million people away from really great numbers. That's a strategy oh man so kind of what are you traveling for right now oh uh i was in i am in san diego for at least for a couple more hours for the weekend

for a half marathon. What was your time? It was one hour, 11 minutes and 16 seconds. Wow. I have no idea whether that's good or bad. That's, that's, that's pretty fast.

Yeah. Yeah. So, so since I've been listening to the, to the show more, there are a couple of things that stand out like one is that it's never not funny to me when bryce gets 10x i mean i laugh every single time you would think it would get old but it never gets old i'm laughing i'm giggling in my desk people like what is he listening to

i'm like i'm listening to bryce be low-key trolled by his co-host and it's amazing and uh another thing is um there was one episode we were talking about what the universal algorithm is uh you know and and you guys were trying to figure out a name for it and i was just yelling the unigrhythm at my terminal which is the the best slash worst name for the universal algorithm um and and the the the last bit of outstanding business is you were also talking about what alternative names you could come up with for ADSP, like what initialism it could map back onto. And my favorite one is, oh, damn, shit's popping with Bryce and Connor. But the funny thing is, like, as soon as you said that, I could not stop thinking of like four-letter initialisms. Like I came up with like 50 of them that day.

I don't remember any of them except that one. But I mean I was like – I literally – I couldn't sleep that night. I was like, oh, that one works too. I was like – I don't know if you guys have trouble falling asleep. But this is what my brain does when it's time to lay down. I'm like thinking of stupid shit that doesn't matter and I can't stop thinking about it. So yeah, that took over my brain for about 24 hours that's pretty fun this is fantastic odd damn shit's popping uh that's clearly gonna be the cold open uh

apparently we need to actually really read the book adsb because we've uh we've talked about pascal a bit now yeah do we both own it i don't think i actually own it i have a dragon book and i have eop i don't think i have it because i was looking for it when we were recording the episode the other day well that's blasphemy you should own it yeah i've heard it talked about a bunch i've never read it either i've read eop like you know multiple times uh because because you have to to it, you have to read it multiple times. But ADSP, I've never actually read. EOP is like, and so that's Elements of Programming by Ag Stepanov.

And Paul McJones too. Yeah, and Paul McJones. Sorry, sorry, Paul McJones. Well, I mean, to hear the telling of how the book came to be, like, and you should have Sean talk about it. It's really kind of fascinating. But, you know, Sean kind of made room for those guys who were Adobe employees at the time to, like, write this book kind of on company time. And the way he tells it, like, Stepanov had all these great ideas and Paul McJones was the one that kept pushing him to finish. So, like, they co-wrote the book together. But the point is that, like, without Paul McJones, the one that kept pushing him to finish. So like they co-wrote the book together.

But the point is that like without Paul McJones, there is no EOP, right? It wasn't just like – and also Paul McJones is here. He was like the guy who was the motivating force to get it finished when Stepanoff had these great ideas but that he didn't have a lot of follow-through. That's from – again, Sean's telling of it. It is a very good book. And like I really don't read Berman books, but I have read a good chunk of this one. Yeah, and it's so dense that like I think I mentioned this actually last time I was on, but it bears repeating that like I took the first, I want to say six or seven pages of the first chapter.

And I turned that into a one-hour talk about how to design types and why you make the design decisions you make. And it is incredibly useful because one of the things that I found when I first started working at C++, you know, you get this multi-paradigm language. It's got the legacy of C stuff. It's got the newer style stuff. It's got all these idioms from the newer stuff and all these different paradigms that usually come from the newer parts. And it's really overwhelming for a new programmer, right? You know, it's like, oh, well, I've seen people use getters and setters and I see people put public data members. I don't know which one to use or why. And that's just one tiny question, right? There's dozens of questions like that. And if you have some kind of rubric

around which to make designs, and I think those first few pages of the first EOP chapter do that, it makes everything clear. It makes it clear, like, why do these things work this way? Why should I make decisions? What's the basis for doing so? So that book is really amazing. The later parts of it, it's interesting because later parts of it are like all about like algorithm design and you kind of see like where parts of the STL came from and stuff. But ultimately, if you already know the STL and use it, I think the later parts of the book, while they're interesting or not as revelatory as like the very first chapter, which is so dense. Yeah, it's so dense. And if you internalize that first chapter, it's huge. A large chunk of the rest of the book is about iterator abstractions and different methods

and philosophies for iteration and algorithm design. But the first chapter is called Foundations. And I actually have my copyright here. I'll read. There's a little summary at the start of each chapter and I a different font because they're like key themes, that represent different categories of ideas in the computer. A central notion of the book, regularity, is introduced and elaborated. When applied to procedures, regularity means that procedures return equal results for equal arguments. When applied to types, regularity means that types possess the equality operator and equality preserving copy construction and assignment. Regularity enables us to apply equational reasoning, substituting equals for equals to transform and optimize programs. So there's a lot of the philosophy of value types in C that this chapter also talks about the regularity of procedures and that in, in Stepanov's worldview, um, regularity was something that was not just

about your, your data types. It was also something that, that, that he intentionally, um, introduced this one overarching concept and then applied it to both types and, uh, procedures. Yeah, absolutely. And, And that, you know, your intuition from a functional programming language of what a function is, is the notion of regular function more or less, right? I'm not sure if there's any concrete differences. I think there's basically the same thing. But it's very similar if it's not exactly the same thing for some technical reasons. Like you can think of it at the high level of abstraction as being like a function from a pure functional programming language. And it's nice because like you can reason about things so well with pure functions, right?

And so that's why functional programming languages are popular to the extent they are. That's why people like them. That's the value that you get from them is that the ease of reasoning that you can apply to them, right? And, you know, whenever I see a function with an out ref or pointer param, I'm like, why is that there? Like, sometimes you really need it. Like, let's say a constructor, right? There's no way to return anything from a constructor. So you have to put an out param to get something out of a constructor if there's some reason to do that, right? It doesn't come up very often, but it does come up. But like regular functions, like, you know, return a tuple, dude.

Like take that value as an input and return as an output. Now there's some things, there are partial exceptions to that, like passing very large objects, you know, in a non-inline function that doesn't really work without making a big copy. So there are some things you should do that, there's some cases where you shouldn't follow what I just said and just pass in a value and pass out the value. But very frequently people pass out parameters that are like a Boolean succeeded or not or something like this. I'm like return an optional.

It's so much easier to reason about your code that way. And it's just easier lexically just to read and write it. Like if you have this extra bool sitting around that you have to pass in and then it's just hanging around, you know, that's just problematic for its own kind of reasons. Yeah, totally agree. You know, one of the fascinating things about this book in general, and you see it just in like the first chapter, is like, yeah, like from that description, it sounds like this is like going to be like a very abstract, very theoretical book. But that's not what it is. Stepanov is very good at building up theory but also remaining pretty close to how computers actually work like in in in in the section of this um chapter where he uh defines what like a value is um he he's talking about you know like uh representations

in binary um and like he's he gives examples you know like like uh talking about specific examples of representing you know floating point numbers and iEEE 754, like very low-level stuff. And so it's in no way, I very, um, practical, uh, book and in his ability to, um, uh, to tie together both, um, how computers work and how you get performance on those computers with,

you know, uh, uh, good computer science theory is really what makes it such a strong book. Yeah. So if you've been persuaded by this, head over to Amazon, use promo code.

Shit's popping to get your copy today. It's actually out of print, which is kind of sad, but the good news is because it's out of print and stepping off of McJones, like signed off on this and they got the publisher signed off on it. You can get us a free PDF. So anybody who can hear this and hasn't checked it out, you should do it. You should grab the PDF. One of the things I think is so great about the abstraction of an iterator is that, like you said, he started with what is the computer doing, and let's make abstractions that generalize that. So there's a notion of a cursor in other languages. I think maybe Rust does something like this where it's like, you know, you've got a reference to the object being indexed into and then some value that says where to index into the object, right?

So that's your representation. So it's an index. So, you know, one of the nice things about that is it doesn't get invalidated as long as the size of the thing you're pointing to exceeds the position of the index. And you can do some very easy checks to make sure that's still true, unlike a pointer, where you can have like, it's such a pointer pointing off into space, you have no way of detecting that. So some advantages of not doing it that way. But stepping off was coming from the point of view that like, pointers are fundamental. This is how the computer works. This is how your ISA works in your chipset. Doesn't matter what ISA it is, it's using pointers. It's using like the addresses of things to refer to locations of memory.

So those kind of considerations are in there. And, you know, I know there's a lot of people that, you know, this has a more broad appeal than just C++ people. And that book uses C++ as an example. But really it's a book about computer science. And that's the thing that's interesting to me is that outside of C++ circles and even, you know, a subset of C++ kind of community, it's not a well-known book. But really, you can take all those lessons and apply it to any language, right? Like there are fundamental ways of writing code that's easier to reason about, easier

to get right the first time you write it, and harder to make mistakes and stuff like that. It's just really, really good stuff. Yeah. So, so, so on that, uh, uh, topic of, you know, uh, the iterator abstraction, the, when, when he introduces iterators in this book, um, he, he writes, uh, iterators are a family of concepts that abstract different aspects of addresses. And this is right after a paragraph where he basically explains what a memory address is and this idea that every object has a memory address. And so I think that's very interesting that the way that he presents iterators are exactly like what you said.

This is an abstraction. This is a more general form of an address, of a pointer. Yeah. And I think that that's not what a lot of our mental models typically are of iterators. Usually we think of it as, oh, well, this is something that abstracts iteration. But really, it was designed from the ground up

to be an abstraction of the hardware of this notion of a pointer. You know, one of the things, so I've been dealing with JavaScript a lot lately because I've been working this data visualization tool that's a web-based thing at work. And one of the things that kind of gets me is I know that people that deal with interpreted languages in particular, but, you know, most languages that aren't, as someone once called them, a semicolon language. I think it maybe even came from this podcast or someone called them that. But, like, there's a whole class of languages for which you just don't have to know what a pointer is, right? And then when people go to C and C++, they're like, whoa, what is this pointer thing? But what drives me crazy about that is you already deal with a language that everything is a pointer, right?

And you just had to internalize all the rules. And then the syntax of dereferencing or taking a reference to something is fixed. There's not options of how to do it. And it's also the times in which something acts like a pointer and doesn't are fixed. And you just have to know the difference. And you've already internalized all these rules. So like, you know, in JavaScript, you can't write like a swap function, right? You can't say like, given values A and B to this function, let me swap their values.

Like you just can't write it because, I mean, I think maybe you can do like something where you like stringify the JSON and then parse it and then you get a new object and you take that from B and assign that to A, and then you assigned A to some temporary. So you could do some funky stuff, but you can't just take these two values, which are pointers to two real things, right? And you can't say whatever they point to, make them point to the opposite of each other. That's just not something you can write.

And so if you do something like A equals B, you're assigning the pointer B over the pointer of A. So now A and B now point to the same thing and they've shared state. So it's an inherently non-regular language. It's really hard to reason about. If you make mutations to some parameters that you're passing, like it just looks like a value parameter. Sometimes you use it as a value. Sometimes you assign to it. And when you assign to it, you're assigning over the local copy of the variable. But if you assign through it using a dot, like mutating operation on the object, you're actually

mutating the object you pass to the function, and it's visible from outside the function. So whether something is a local change or not is subtle. And I mean, it's like really hard to reason about this code. And then people are like, but pointers are so hard to think about. And I'm like, are they though? Like, I just don't, you know, just use values and you're great. You know, I, I, I cannot tell you the number and I, I am by no means, um, uh, an expert Python programmer. I think I'm, uh, pretty bad at writing Python code. And I think most notably the problem is that I don't, I don't know, like the Pythonic way. I don't know, like, what's the idiomatic way to write Python code. So I end up writing Python code that looks a lot like my C++ code.

But I can't count the number of times when I've been writing some Python function and I've been like, I'm confused. Am I working with a local copy here? If I modify this thing, am I going to modify the thing in the calling function? And I just don't have the mental model for it. And I mean, I think that any language like that, other than a language, something like maybe like Hilo, where it's like purely a value-based system or like, you know, a lot of functional languages where it's purely value-based. If it's not a language like that, then you've got some sort of object model that has some form of references and shared state and some form of abstraction over pointers. And, you know, okay, the C++ one has a lot of foot guns, but I don't think that it's necessarily harder to understand than the object model of like a language like Python or JavaScript. It's just different. It's just quite different. I think that's right. And in particular, the thing that excites me about Hilo

as a project and as something that might be the semantics of what its value oriented model looks like might be bolted onto C++ as a safe mode at some point in the future. The reason that is more exciting to me than doing a Rust version of it is you know rust took the problem with writing code in c plus plus and c is it there's reference semantics everywhere the shared state everywhere when you have reference semantics right and so they said well let's make it harder to write those mistakes that we write we use reference semantics.

And so they have this very elaborate checker that doesn't let you write things that you know are safe, even though they're not because it doesn't have the proper heuristics to cover that case. There's a few warts like this, and it takes a long time to compile. It's a middle model that everybody has to get ramped up on and stuff. And there's nothing inherently wrong with it, but it's just like when I write, when I write C++ code, everything's a value and I don't have to do this, right? I don't have to worry about references and whether something's dangling or not because whenever I have pointers, they're like implementation details inside of stuff, right? And everything's a value at the top level. And so when you write code like that, you don't have to worry about these things. And Hilo seems to be embracing that. Like, oh, well, let's instead of like trying to get all the weird stuff right, let's just not do the weird stuff and not let you do the weird stuff.

So I had this housemate in college. And right after school, he went to teach English in Japan for a while. And he said while he was there, this was in like the late 90s, like 97 or something. And they had a few models of cars that were coming out at the time that had TVs in the dashboard. So as the driver, you could watch TV while you were driving. And everyone who bought one, yeah, sounds great idea, right? So all these people with these cars, they were getting in accidents all the time, as you would expect, right? So instead of the government saying, hey, you can't put TVs in the dashboard of cars,

they instead said, if you buy a dashboard TV car, you have to take this government-sponsored class that teaches you how to drive your car safely while watching TV. Right? And to me, that's rust. Like that's what rust has decided to do. They're like, you know this insane thing you chose to do, like use references for everything? Let's make that safe. And I'm like, why? Why do that?

I mean, I understand. Like has good results. Right. But, but I think there's a, there's a better way of slicing the same problem. Yeah. I mean, it makes, makes, makes one wonder why hasn't something like, uh, been, been attempted before. I think, I think, um, I think that the challenge that you have with both something like high-low and and rust is that you you lose some degree of control um uh and and for systems programming that that that can that loss of control can often lead to a loss of uh performance loss of ability to write something in the the fastest way yeah and that's that's why we've we've oh we that's why systems programming has gravitated towards languages where you have a great degree of control and a great degree of what comes yeah yeah so okay speaking of like future stuff that i'm super excited about uh the uh i think you were maybe in this session

uh bryce but at the last c++ meeting we had a session on uh metaprogramming and reflection yeah and uh you were in that session right and they showed like so there are some people that you know work on compilers that have taken this on as like we're going to implement something and and and write papers supporting the implementation and they were so much farther along than i think anyone in that room besides them suspected. And now it looks like there is no guarantee, but there is a chance that we're going to get that for 26. I think it's pretty likely that we'll get reflection in 26. I think it's likely, too.

But I didn't want to use the L word in front of all of our listeners because I don't want to build expectations of something that might not happen. But I do think it's likely. Yeah. I don't use it lightly, but I like its odds. Yeah, I do too, especially because everyone is excited about it. And even people that were in the room that had competing approaches were like, no, no, that's fine. You guys have done it.

You have an implementation. It's working. People are building cool libraries with it already with the reference implementation, with the demo mode of your program, your compiler. And people are just like, yeah, let's just get it in. Let's just get it done. And that kind of thing, once people shift away from like,

but you didn't do it my way to like, let's just get it in there, things tend to move pretty quickly. Yeah. Yeah. So I'm really excited about that. And then you know who you need to get on this podcast is Michael Park to talk about reflection because he has a reflection proposal that no one has implemented yet, which is the big, I think, blocker for it right now. Wait, he does or pattern matching?

Oh, I keep saying the wrong – I've said that to multiple people. They're like, I think you're confused. I'm like, yes, I am confused. No, no, pattern matching is what I was trying to say. But, yeah, he's got a really, really interesting proposal for pattern matching that is like really well thought out he's done a huge survey of I think like 13 different languages that have pattern matching in it you know that already in some other language in existence and he could try it out and see if the semantics and so he's done the C++ version of that and it's really great and

the cool thing about it is like he's been thinking about this for a very long time. Like, I think the first conversation I ever had with him about this was in, like, 2017 or 2018. I mean, like, it goes back a while that he's been working on this, right? And so whenever someone has a question, like, you know, he'll bring up, like, the paper, and he'll show you, like, the semantics. And he even has, like, you know, part'll bring up like the paper and he'll show you like the semantics and even has like, you know, part of the grammar for language and stuff. He's thinking about the grammar level too, so he doesn't miss anything. And he'll bring something up and you'll say like, oh, but what about this? He's like, oh yeah. And then he'll talk about it like it's a new idea that he's never heard before. And at the end he's like, yeah, so that's why I'm not doing it that way because like,

I don't think it works for the reasons we just came to like you try to stump him or you try to come up with a what about and then it never works because he's thought of everything um and when people have that level of fluency with the topic it's just really exciting so anyway i don't think there's any chance that'll happen by 26 but i'm really hoping that we can get that in the 29 time frame i think that'd be awesome and if we had both of those things i mean that would be another seismic change in how 29 time frame. I think that would be awesome. If we had both of those things, that would be another seismic change in how you write C++, I think. I think just reflection alone will be pretty

impactful. If we get reflection in 26, it's going to make it a major release. I've been giving this talk, C++ Horizons, where I talk about the three things I'm most excited about and the future of C++. It's reflection, pattern matching, and senders. And I was so excited to see that we're making progress on reflection because it had seemed like it had been stalled for a while.

And I was at – so I was in Switzerland a week or two ago going to, um, uh, to CERN to give, um, a couple of talks there. And I got to go see the particle accelerator underground, which was super, super cool. So many wires and they cut every wire to length. So there's like no extra slack in the wire. It's like they're, they designed this thing and then they're like, all right, we need a wire that's exactly this long. It's amazing.

We'll, um, we'll put some pictures on, uh, in the, in the show notes. Um, but when I was there, um, a group of the CERN folks, they scheduled a meeting for me and I thought it was just going to be like, let's talk about data layout and reflection and whatnot. But no, it was like 20 people from CERN and they had like a presentation and they were like, we want to convince you to care deeply about reflection and they were um they were talking about like their use case as a use case like i think a lot of people hear about reflection they're like oh that's cool like i can write the the function that convert that like you give it an enum and it gives me a string of what the enum's name is and that's the example it's used so often but um these cern folks they use reflection to optimize their data layout um and the the problem that they have is that they

got this giant particle accelerator machine and it just generates a ton of data just like tons and tons of data they have have like X bytes of data. You know, they're stored and they've got this throughput problem. And so they need to, you know, it's not always a like compute bottleneck or a latency bottleneck or a storage bottleneck,

but it's just a throughput bottleneck if we've got so much data and how do we process it and get it through? And one of the things that they've done in a lot of their experiments is they have some kludgy form of reflection where they can, in a certain place, they can switch from array of struct to struct of array, but they can also do things like, oh, hey, we have some technique where we can change the data layout to make this representation fit smaller in memory. So we can save like 40% memory usage. And like you actually, you see this a lot in a lot of other applications too. Like there's the, you know, there's like a GCC attribute for like packing your structs.

I know a lot of people use stuff like that. Like one of the really cool things we can do with reflection is we can build libraries that do all sorts of compile time optimizations of our, of our data types and our, and the layout of our data. And that can have such a huge impact. And like what they're doing today, they like have to use like compiler extensions or just like macros, just like piles of macros. And it sounds so painful.

And like this future where we have reflection, it's going to be great. It's going to be so much cleaner to do those things. One of the things that, so, you know, I have this expression type of library, YAP, it's part of Boost. And there are some severe limitations in what you can and cannot do because like you know essentially what you want to do with expression template libraries you want to capture some expression as uh you know a roll your own ast type and you can see all the pieces of it and then you have some transform that like walks the tree and does stuff, right? So if I had the reflection piece

that fed into the pattern matching piece that then fed into the metaprogramming piece, I could write like the one expression template library to rule them all that would just supersede anything else, right? Like you could have one framework that said like, here's how you specify a transform. And the transform is just regular code because like the problem with doing transforms on asts is that you have to be

like oh i have to know what your funky node type is and all this stuff and i have to say like oh well i match this kind of case but if i don't match the exact kind of case i have to have like this loose loose matching and then what if i match the wrong thing because i uh there's a loose match that i was trying to hit but then i also hit this other one that i didn't want to hit and you know it gets really complicated really quickly. But if you could just write regular code that just says like, well, if this thing has such and such on the left and such and such on the right, then let me recurse. And then it's just normal code like with ifs and fors and stuff, then, oh, man, it's so much nicer. I like to think of that as it's the Louis Dion revolution in metaprogramming that we had, where it used to be that we would do all of our metaprogramming with this type-based metaprogramming that was like a completely different world than what we do today, which is where today we do value-based metaprogramming, as it's called, or like constexpr metaprogramming, where you could just write regular C++.

And like, it's just regular C++ that's constexpr or constabout. And it's just so much, so much cleaner and so much better than how we used to, how we used to metaprogram. Yeah, yeah, totally. Well, I was just gonna say, I'm just really excited for it. Because like you said, it is like, if you think about before you could say if constexpr, right? What you had to do was like make a bunch of, make a struct that took template parameters and you had to have a bunch of partial specializations

of that struct that some of them were, some of them win in this case versus that case. And so like, you know, I had this one thing inside of YAP that had five cases in it. It was a function that took a bunch of different kinds of things and then returned a common return or common sort of operation on those kinds of things and different return types.

So the way I wrote it first was using 17. I said if constexpr, some predicate, and then I changed these four alternatives after that. Those were the five cases, and it was easy peasy. Then I went back and did it for the 14 and earlier version, and I had to do this partial specialization thing where the right one, one in all five cases. And I mean, it's the kind of thing where when you're in it, you can write it.

And then when you look at it six months, you're like, I don't, I don't know why this works. I don't, I don't get why that specialization is better than that one. You know, like C++ is essentially just a series of complicated lookup systems glued together you've got like the the specialization engine you've got the overload engine you got a couple others and yeah like any time you have to write some some form of pattern matching or dispatching that relies on partial specialization or overload resolution

it's like unless you're a real wizard, you're gonna have to go look up like, okay, like, why does this match versus like better than that? Whereas if you're just writing like traditional, like, you know, if else, like constructs, it's a lot, it's a lot simpler to figure out your logic, just by the simple case that if I've got like, you know, branched if-elses or, you know, pattern matching, the pattern matching proposal, its first match wins, right? So like, obviously you have to make sure that, you know, the things that you want to match, match, but it's not like overload resolution or partial specialization where it picks some priority and it's not necessarily in lexical order. Yeah. Yeah. You have to just have an overload set that works out. And that's what I was going to

say next is that like, this would take those if constexpr chains and turn them into regular ifs. So that's just, you know, it's not the same order of magnitude difference it was from like the old bad days of partial template specialization but it's better because like if constexpr is already kind of wonky right like if you don't if you don't have everything in an if else chain it doesn't work right like you can't have like the the typical pattern where you say like if something return early and then later on i just do the regular logic and return because now i have like if the predicate is true in the if constexpr now i've got two kinds of returns that might differ from each other.

So I have to have basically like an else. And that means I often have to repeat code in multiple places if I have if else, if context for else stuff nested. And just making a regular ifs is just great. You know, it's really amazing. So all that stuff I find super exciting. And I'm really looking forward to having it. But, you know, it's funny because we talk about these things and I'm like excited because this thing might make it in 29 it's like six years away at the earliest and yeah it's just the pace at which things happen

speaking of you know c++ 29 and having to wait for pattern matching this whole time I've been waiting to ask Bryce would you like to revise what you said in our most popular episode of all time? If you ignore the first, you know, five or six, because those get more downloads. Episode 150, which we titled is C++ dying, I think just broke 5000 downloads. And usually we get like two to three within the first month anyway. So so I don't, if you look at our episodes, no episode breaks 5,000 since like the first few. And you famously said that you would be surprised if C++ ever shipped a major language feature. And now you're saying that it looks like in 26.

But now you're saying it's likely that we'll get reflection in 26. So comments from Bryce 11 episodes later in episode 161. I don't think that the fact that this thing has surprised me and is likely to happen is indicative of... None of the systemic problems that I've highlighted with the C++ evolution problem have changed or been fixed. So, Bryce, aren't you concerned about your pants, like, getting caught in the gears when you backpedal so furiously? I mean, I think it's great that we'll get reflection. But I think that with a better evolution process, we would have gotten reflection a lot earlier.

I mean, the fact is that the proposal sat idle for two to three years and that everybody thought it was dead. And this is a programming language that millions and millions of people work on. We should have had a better process where we didn't just have like a long delay in work on that just because of the volunteer nature of our process and variety of other factors. So something occurred to me. This is actually – so Michael Park just got married and he brought his fiancée with him to the last meeting. And she was asking about – Yeah, yeah.

He got married like last week, week before. Yeah. I did not know this. Yeah. And he – she was asking like some questions about the process and how we do things and she was just curious about it and and i i really you know i was explaining something to her and i had this kind of realization that you can only have when you explain to someone and you like step outside your normal frame of reference kind of like the stuff bear phenomenon where you explain to a co-worker like what your bug is and then you fix it you know in your head as you're explaining it so um she had asked something about like who who

are the typical people that show up to these meetings? Like, why are these people here and not other C++ programmers? Like, what makes this group show up to the meetings? And I was like, well, I think a lot of people are kind of volunteers, and it's kind of like an open source project. And I said, you know, there's other programming languages that have big foundations that are well funded, and they have people that are like kind of paid to work on advancing the language in the standard library and stuff. We don't have that i mean we do have a cadre of people that does that but it's it's a minority for sure and um and then i said something that i had not thought of before maybe it's obvious to everyone else but i just realized this as i was saying it to her was

that like oh i think the reason why we don't have such a thing is that we guarantee backwards compatibility. And so when you guarantee backwards compatibility, no one has to care about what you're doing in the language. They can continue to use it as is. But if you do something like Python 2 to Python 3, and if that's on the table, then everyone is going to send someone to the committee and being like, don't break our tool chain that we need to do our work. Right. And so people, people are allowed, like, you know, I work at a company with 3000 C++ programmers and I'm the only one that goes to the committee and they don't pay me to do that. Right. Like they, they, they, they support it, but like, it's not part of my job. Right. They don't have anybody that they say like, go make sure that this thing doesn't break on us because they know it won't because we don't make breaking changes really. So that's kind of interesting to me, right? Like the big thing

that prevents our evolution from moving forward is break is, you know, unwillingness to break backwards compatibility, including ABI compatibility in a lot of cases. And yet that's also maybe one of the things that keeps people from being engaged with the standardization process, like on a company level, like willingness to support people and go work on this stuff. So, you know, we really have this problem that it's an open source project and any open source project lives and dies by, you know, what people feel like working on. You know, if no one feels like working on a particular feature, then it just doesn't get worked on. And if someone gets burned out, then that feature goes away. Right. So that's just how it is. I had never thought about that. Yeah. So, you know, if, if you take that as like, you know, as that is, if at some point C++ does decide to have like you know in C++ 32 or 35 we are

going to have like a Python 2 to 3 where like here's your one chance to get a bunch of features in you would expect that there's going to be like a huge uptick in the people like coming to those few standards meetings

I don't think that we want to have a fear-based collaboration model. It's an interesting point. I had never thought about that before. I think all programming language communities have problems. Obviously, the Python community, while it's great,

I think it's great, I think is run a lot better in many ways. There are many things about the way the Python ecosystem operates that I'm envious of, I think is the way I would say. But they've had their share of problems. Rust, again, I think very envious of how the Rust ecosystem ecosystem works and i do think it's better than the cepa specific system but they've also had some problems especially more recently um there's been a lot of uh i'm not going to try to figure out how to classify growing pains i think it's categorized categorizable as growing pains yeah good way to put it yeah because i mean their their their um community is exploding in science, right?

And that's always problematic. And, you know, just bringing new people into the fold and not losing your culture is hard. But I'm not sure if – I'm not sure if the – I think that the backwards compatibility is something that hangs over our head. But I think that the real reason that more people don't get involved is that the decision making is so slow and the process is so arcane that it sort of keeps people away. And, you know, it's hard for any person or company to decide on a 10-year investment. I think really like the backwards compatibility issues are a big part of why it's so slow, especially for language evolution. For library evolution, you just throw it against the wall and see what sticks.

We put a lot of stuff in the library. Then a couple of revisions later, we're like, yeah, we don't need this anymore. But with language, you put it in there and you're married to that. You're never going to get that out of the language. There's one major counterexample that basically no one ever implemented. So we could strike it, which was export and everything else like, you know, not modules export, the old export, the template export. Yeah. So, yeah.

Anyway, you know, but I think what you're saying is right. Like it's when you tell someone, hey, you know, people have come to me in the past, right? And said, like, hey, why doesn't this work like this? And I'm like, write a paper, I can help you. And like, okay. And then, and then it's like, yeah, so then you need to go to a meeting, or I can champion it for you. And then when they come back with comments, like you need to, you know, address those comments, and so on. And like, it's daunting. And people are like,'s daunting and people are like yeah i'm not gonna i'm not gonna do all this this is too much right yes yeah it's it's a lot of work and and the whole you know and i i'm always big proponent of this like one you know we have all this iso process and procedure which is very arcane but then like just just within the committee there's plenty of um uh there's just it's it's too insular in many ways like like

why why do we have to number the study groups if you're new to the process like sg 25 or 27 like yeah that that has no meaning to to to an. Well, even among insiders. I have referred to SG9 and people are like, which one is that again? Like that's the ranges one. They're like, oh, yeah, right, SG9. Okay, great. I made a big effort when I was chairing library evolution to never use the study group numbers. I would always type out the names.

Yeah, that's a good policy. I think the same with paper numbers, honestly, too because no i don't have my own papers numbers right i'm yeah paper numbers yeah yeah and so just like like you know the reality is that the process the evolution process wasn't really designed it's just sort of a thing that like we we never sat down and thought like how should we structure c++ evolution to be sustainable, to grow the committee, to be able to handle growing the committee, to be able to set direction, make decisions. We never sat down and had a meeting about how to do that.

It's just sort of been like this ad hoc thing. And I think that's led to a lot of problems. And on top of that, there's just a lot of infrastructure problems, and there's a lot of infrastructure problems and limitations from the ISO process. And so the fact that reflection looks likely to happen doesn't change my opinion on our overall process issues. I think reflection is going to be the story of a feature that succeeds in spite of the problems that we have. And also, I'm sure that between now and when reflection ships, there will be some amount of holdups and drama and problems, and at least some of them will be caused by the limitations of our process.

Yeah. Yeah, and the thing is that this really leads to something that we have a lot in the committee, which is like little tweaks, right? Because a little tweak is some of the bite-sized, you can be like, oh, I don't like that. I could fix that. Let me write a paper for that.

And you write a paper for it, and people are like, yeah, I see there's a problem. Let's fix that. And then your thing goes through and you're done. You move on to the next thing. And it's nice and tidy. And then you've got something like ranges, which took over Eric Kneebler's life for like, you know, years. And if you're willing to do that and stick with it, then it does pay off in the end. But like when I say took over his life, I mean, for real, like he was just doing nothing but this for a very long time. And, you know, in terms of even professionally, like he was at one point, working on it as his day job, even. So like, you know, exactly. So he was, you know, really like all in on it, right. And, you know, there's other people like, you like – I don't know how much of Gore's time was monopolized by Covertine stuff, but it definitely was a long time getting it from – if you look at the timeframe in which he was writing papers, it took a certain kind of person. I mean, I think we have a pretty self-selected group of people, like C++ programmers in general,

who are very comfortable with the delayed gratification because that's what it means to be a C++ programmer. But there's limits to that for most people, and the limits are far shorter than six years for most people. Yeah, yeah. I mean, I think that's, you know, maybe that's true of any language. i mean i think that's you know maybe that's true of any language maybe it's the case if you want to do some drive some big feature in python it's going to take longer than you expect but um my my my impression is that uh we um we move uniquely

slow slowly yeah yeah i think i uh i submitted a talk to pycon just a couple days ago called the power of python uh which is the point of the talk is to basically say that i think python is like the best programming language for being productive like nvidia nvidia is not necessarily gonna ship a bunch of whatever compiler stacks written top to bottom in python but now that i'm in research i basically do almost everything in python like i want to write c++ code i'll write python to write me my c++ code like i i can move so fast with python and not just not just the language but like the ecosystem around it yeah um and also it's in this situation now where like Python is in a,

like a state where the rich are going to get richer because LLM models, they do best at like generating Python code. Cause the corpus of Python code is so large out there. And there's something to be said about like, like you, you made me think of this exact when you said like C++ programmers are okay with delayed gratification. Cause we're constantly fighting with the compiler and waiting things for to compile and with python it's the exact

opposite of that like sure maybe you didn't write it correctly the first time but like it's just so nice to like write code hit a button and things are running um yeah yeah and uh and like i just i get frustrated sometimes like i'm supposedly a ranges expert and then i'm trying to write some code that i said I could get working in three minutes. I said this in a meeting on Friday and I was like, give me three minutes and I'll have the ranges code 40 minutes later. I've like,

Oh yeah. GCC 13.2 doesn't implement ranges. Colon colon two MSVC, uh, has some implementation thing that doesn't work and you need a macro to use it on God book, you know, compiler Explorer.

And like, then I went to this internal tuba I had written, like went away from standard ranges to this range of E3 finally got something working. And I was just like, what the heck? Like 40 minutes during a meeting. And I,

in my head, it should have, should have been like a three minute thing. Yeah. Yeah. That's been my big gripe actually with, with concepts is that, you know, the, the major use case for concepts in the standard libraries and the ranges stuff, we're starting to add them to new things as we add them. But basically the only big chunk of work that came in with concept constraints was the stuff in ranges.

Well, whenever I try to use it, if there's a problem, I'm like, now what? Like, I mean, I'm, you know, i'm an expert level sql slisper guy where if i get a big huge template instantiation stack i could i could debug that like i could figure out what the problem is with the concepts often it's very very much depends on which implementation i'm using with with clang i get this like this concept check failed because this subconcept check failed because this one failed because and this because there's a nice chain of them. And with GCC, it's like, hey, shit's broke, man. Like, no, you go. And it's the same way with MSVC, too.

Like, they just don't have very good diagnostics. And there are some technical reasons I don't fully understand for why the version of concepts that we got is hard to write diagnostics for. And people are really worrying about this when we're standardizing it, whereas the old one lent itself to much better diagnostics. And again, I don't remember the technical reasons why, but I remember the selling point. You know, if you look at Doug Greger's early prototype and he was giving talks like, here's what you get,

like the famous example of an l-form template from like someone's book that people used to refer to a lot was uh you know let me call stood sort but i'm calling it on a list on like a stood list right uh so i'm calling stood uh you know for my list l i'm calling uh sort l dot begin l dot end and i get some weird message that's like way down the bowels of like the sort algorithm itself saying like hey this is this doesn't you know make sense this line and i'm like why doesn't this make sense and then you know doug gregor's prototype implementation the old version of concepts the ox version of concepts before 11 um it said like this doesn't work because that is the wrong iterator category and it was like yeah yeah that's what that's what we want we wanted to say like this

is the high level problem with your code and this the fix is like you just can't sort that maybe you should look and see if there's a member sort turns out there is and you should use that instead right so that was really cool and then now if you if you do the same example i'm pretty sure it gives you something along the lines of what you used to get with just unconstrained templates that is to say it gives you a a big mess of of an answer for why like std ranges sort doesn't work um but it doesn't um it doesn't give you this high level thing of like this is the thing that changed your code to make this work or not even just to make it work but this is why this won't work um i i feel like that's really sad and in fact i have um you know a lot of the code that I write is for Boost. And so like a lot of stuff that I've been writing with concept constraints, I've actually been putting like if use concepts, here's the template head with the concepts in it.

And then else here's the template that's got a problem and then recompile so that I can get the massive spew of template instantiation crap that I'm supposed to dig through because that I understand how to work with. I mean, that's not what we want to – that's not where we want to be. That's not a good state of affairs. Yeah, that's very sad. Can you see my screen? Uh-huh. Wait, am I sharing the right thing? No. Do you see the Godbolt link?

No, I just see something about the Aspire Lounge. Oh, I shared the wrong one. Hang on. It looked like it was the right one. I thought you were going to pointedly tell Connor he should be in a different lounge or something. I mean, the reality is Connor probably doesn't were going to pointedly tell Connor he should be in a different lounge or something. I was like, where's this going? The reality is Connor probably doesn't have access to any of the better lounges. Oh, Bryce is fancy. He wants everyone to know it.

As soon as Bryce said that, I was like, here we go. Zach's about to take him down a bit. All right, let's see if GCC is any better here. We're looking at what is the diagnostic that you get from the calling stood range of sort on a list. Usually I wouldn't allow Bryce to screen share, but this is the holiday special, so we're doing whatever we want today.

I'll allow it. Thank you, Connor. So, Bryce, I see you have a lovely Hanukkah bush in the background. Yes, yes. Well, I have my girlfriend's mother and 12-year-old niece are arriving tomorrow from Poland. Neither of them speak any English. So it's going to be, and they're going to be here for two weeks so it's going to be and they're going to

be here for two weeks it's going to be a ton of fun uh i saw that tweet you sent out and i love i love that like 10 of people that reply to your tweets are always just giving you a hard time and my one one person said look at bryce breaking up about the fact that he's got a girlfriend subtly i have a girlfriend parents nbd you know so i suppose my grandmother blah blah i suppose to be fair we would need to also look at um what do you get and maybe we should do that in a separate GodBalt window. What happens if you do this without ranges? Yeah, just say std sort, yeah. Yeah. So I didn't really have time to read it.

I was trying to make it bigger. I was too busy laughing at you to carefully read the code. What is it saying to us here? Okay, so GCC tells us this is what we're calling. Also, wait, can we explain for the listener the code we've written first before we diagnose the error? Yeah, there's much to explain. Pipe down, pipe down. So we've got code where we just create a std list of int, and then we just call std ranges sort on it.

And it should not compile because sort requires a random access range, and list does not provide bidirectional iterators. So with GCC, it tells us, well, no match for call to this function. But of course, the function that you're trying to call is one of these sort customization point objects. So it says no match for call to, and then there's a call expression for std ranges, colon, colon, underscore, underscore, sort, underscore function. So the fact that we didn't, that this thing's a function object and that we don't have a better way of doing the customization points at the time that we ship ranges shows in the diagnostic.

And then it shows the overload set that it tried, which is the call. This is all the candidate functions, yeah. Yeah, but this is the call operator for this function object. So somebody who doesn't understand how it just works under the hood, I think could be quite confused by this. You know, like a naive user, I'm being literal here, would look at this and say like, oh, sort is a macro or something. Because they see it transliterated into doubles underscore sort fun.

And they're like, oh, well well that's not what i call it so this must be like substituting a thing for another thing and i don't know what's going on here so one of these here so so a bunch of them say constraints not a bunch of these so it says she didn't match any overload here's all the ones i tried and um i see at least one that says constraint's not satisfied, but it doesn't say why the constraint wasn't satisfied. No, no, no. Okay, right here. If you go down, it does. Yeah.

So we got one that says requires random access range. Oh, that's actually pretty nice. Yeah. Yeah. But that was in the middle of the diagnostic. It took us a little bit. Yeah. You have to read down several error and note lines to get to that. Yeah. So there is also down here, it says, this is below the failed call. There's something where it says, I think this is where it's digging into why this requirement failed.

So it's a call stack and it starts off by saying required for the satisfaction of something derived from some concept and then required for the satisfaction of random access iterator. And then eventually like the last part of the diagnostic says std random access iterator tag is not a base of std bidirectional iterator tag. Okay. The clang one is a little bit better because the clang one, it also has no matching function for call to object of type underscore underscore sort fn. But then it's got a cleaner list of the overloads that tried and failed.

And the second one there, or maybe it's the first one. Yeah, it's the first one. The first one says candidate template ignored, constraints not satisfied. And then the next line, it says, because std list int reference does not satisfy random access range.

This is what I was talking about when I said, like, I think the Clang diagnostics are way better than MSVC or GCC for concepts right now. Like, this is very nice, right? It says, it just shows you the function. It quotes the line. And then it says, this candidate template does not work because of lack of constraint satisfaction. And then the next line is why, in a way that you can understand immediately.

There's still the noise of, like, double underscore sort fun and that kind of stuff but you know that's that's fine if if the rest of the the experience is that nice but i gotta say like this is a pretty yeah i was gonna say like write it out um with begin and end instead of just passing an l i think they get worse and the thing is that these are both pretty easy cases like if you do anything more complicated with concepts where like the failure isn't at like the top level the identity of the thing like you know it has to have like bi-directional range is like i think what you write instead of a type name range or bi-directional r instead of type name r and so it's like at the top level you have a failure but if your failure is like oh well it's like it meets bi-directional range but there's like at the top level you have a failure. But if your failure is like, oh, well, it's like it meets bidirectional range,

but there's like a requires that like something about the value type has to look a certain way or something like this somewhere. And then you go finally all the way down into the guts of the thing and you dereference the iterator and then it gives you a value type or a reference type if you dereference an iterator. It gives you a reference type that looks wrong. Then that kind of error message is way way worse um you know the the sort of the higher in the structural um matching you're doing on the concept like the higher that it fails like the better the error message is the more it has to go down into it the worse the story is for the diagnostics so so the the free, pre-concepts diagnostic that you get here in both GCC and Clang, it basically tells you that there's no operator minus for your stood list iterator.

This is the whole point of concepts is that it's meant to, you know, check requirements before you go and, you know, instantiate the body of the thing. And so like, obviously, like the underlying problem here is like, okay, well, the list iterator doesn't have operator minus because it's not a random access iterator. And the algorithm assumes that it's a random access that you need to pass a random access iterator and the algorithm assumes that um that it's a random access that you need to pass a random access iterator to it so you know this i think this diagnostic almost certainly is worse because oh yeah it doesn't at any point tell you that hey i needed a random access thing yeah the fact that the names bidirectional and random access never appear anywhere in here. You just have to know that, oh, operator minus

is defined on random access iterators, but not the ones I gave it. There's a lot of inference you have to do. It's also worth noting that in both of these diagnostics, you have internal names. Even though std sort is not a customization point object, it's not like one of these function objects, this diagnostics that we get here,

it still shows the error manifests in std colon colon underscore underscore sort. And it's not std colon colon list colon colon iterator. It's std colon colon underscore capital list iterator. So there's still a lot of implementation details that get exposed. Yeah. Yeah. I suppose we should, sometime we should have Eric

on this podcast and ask him, hey, what's up? How do better? My understanding is that this is, that the language feature itself is kind of to blame for this, not the ranges implementation, not the approach that they chose for ranges. That's my understanding.

But again, because I don't understand the technical details for why the diagnostics are worse with this implementation of concepts, it's hard for me to say that definitively. I do think that this is a, so in this particular case of calling sort, sort is an overload set.

So you have a bit of extra noise here because there's some overloads take, there's an overload of sort that takes two arguments, one of which is a comparator. And there's overloads of stood ranges sort that take iterators. And the compiler sort of has to include those other overloads in the diagnostic because maybe the mistake that you made was that you'd left out an argument. In fact, my AI-assisted software engineering talk, one of the bugs that I have the AI tool try to identify for me from a cryptic diagnostic is one where I omitted a third iterator parameter

to a call to transform that I should have put in there. So it's not like it can just assume that, oh, you meant to call this overload that the constraint failed for. I should only show you diagnostics for that one. Because that may not be the case. It may be that your mistake was, oh, you meant to call the version that took two iterators. And the reason that your argument doesn't satisfy random access range is because it's not a random access range, it's a random access iterator. And you just forgot to provide the second one. And so, because of that, like there's a lot of extra noise here. And that is kind of a little bit inherent to the model. There are certainly

some cases where you have a function or a thing that doesn't have as complex an overload set as a lot of the standard algorithms um and in those cases um i mean i think you are going to get a much nicer diagnostic because you call the thing there's only one overload candidate and it failed it doesn't match because of constraint failure it'll hopefully give you a pretty good explanation of why but you know overload resolution is uh is fun yeah for some definition of fun yeah it's awful awful stuff yeah yeah i mean the summary is just that we were kind of promised that this story would be much better than it is right now, especially given this is a major like advertised benefits of concepts. Is that you would have that name in play instead of operator minus, you would say like, oh, random access versus bidirectional.

That's what I'm missing. Yeah. And so I still don't understand exactly how this is way before my tenure on the committee. I don't understand exactly how the original concept stuff got uh the boot but there's definitely lots of aspects of it that i really like better than what we got including like concept maps which are um if people don't know what that is it's basically like a rust rust trait it's very similar to rust trait where you say like this thing conforms to this concept and here's some glue code that makes it work which is a super nice uh language feature.

If you've used Rust traits, you know what I'm talking about. They're really, really handy. So there's a bunch of things like that that we were missing from the thing that we got. And I think matching on expressions in general is not as nice as matching on archetypes, which is what we had with the old implementation. So you would basically write out like this is how this type should look. And then if it didn't look like that, it's pretty easy to say like, oh, well, this thing is missing like this exact function overload because you wrote that function overload. It's really easy to write that. Like you didn't have this, right? Whereas if it doesn't have some

expression, you're like, well, it didn't have anything that works as this expression, but those expressions are inherently ambiguous, right? Like does star X for some value of my type that I'm trying to match, like star X, like does that mean that it is – like can I draw the distinction between like an operator star that is like ref qualified for only R values or only L values, right? I can't distinguish those two, right? Whereas I could say in an archetype, like it has to have the ref qualification L value only or const L value or R value or whatever the thing is. I can write it out explicitly or I can say it has to have two of them, right? But not all three, something like this, right? And then I can say like, oh, your type doesn't have the exact requirements I need. And let me write you a diagnostic because it's just like regular overload resolutions. Like I couldn't find overload that matches this thing that you

need. And so it's really easy to write diagnostics like that. That's how we write diagnostics all the time for any regular function call. You know, one of the things I really like to have is like type erasure in the language. I think that'd be really cool. But there's really no way to write it with concepts the way we have them right now because you'd like to say like you know make me a a type erased version of some concept name right but there's not a way to do it because then if you have some expression you don't know how to go back from that expression to synthesize like an exact function with an exact signature because there's multiple things that can map onto that expression so you know it's problematic in a lot of ways. And I was one of

the few people that was like, yeah, I don't like this new concept formulation. I think we should not standardize this. And there was a small group of us that were like skeptical. And I don't think we were 100% correct but I think we're on to something that like the old thing had some merit. And again, I don't understand all the technical details so there could be some like complete deal breaker from the original concepts thing that I'm not aware of.

But I definitely like as a user facing like what it would be like to write code both ways, I definitely prefer the old model. I feel that the purported benefits of concepts have not materialized in the way that they were advertised pre-C++20, pre the release of C++20. I also just found it easier to express concepts in the older model than in the current model

where essentially you write usage patterns. express concepts in the older model than in this the current model with the whole like where you essentially you write like usage patterns i find that very um non-intuitive to me yeah yeah i do too yeah we should we should uh we should have somebody on sometime to talk about the old history should we get doug gregor on i mean that would be the person to have yeah that would be nice who did uh i think it was you bryce that told me to talk to doug and he was at the um pldi so 2020 yeah when we were there together yeah when we were there together and it wasn't 2020 though buddy because i'm trying to remember when that was anyways it was i think it was post pandemic quote unquote post oh see um stockings just arrived come bring over a stock

and i want to see the stocking. Welcome to, oh, damn, shit's popping. Take a look at the stocking. So there's another reason why I would want to have Doc on the podcast, which is that when we met him and chatted with him in San Diego at PLDI 2022, I think, he made the bold claim that variadic templates was like a perfect feature. It's perfect, there are no nodes, there were no problems.

And I just, I want to chat with him a bit about that, because I feel like parameter packs could have had some ergonomic improvements. Well, the only deficiency I had with it, I think, was that you couldn't index arbitrarily into

a pack. And he had that as part of the proposal. I don't know if it was the root proposal or the proposals surrounding it. And everyone liked the feature, but everyone hated the different syntaxes that they saw. And everyone was waiting for better syntax to emerge, and then it never

happened. So like they, they acknowledged at the beginning that this was like something that people wanted to do and it was very valuable, but they just couldn't come up with a syntax people liked. So much. So, so all of my years of painfully having to write all of the little quirky patterns is because of that.

Yeah. Like having to tease out like the front or the, you know, the suffix or prefix of something around some value you're looking for in the middle, like all that painful code is not strictly necessary. The perfect is the enemy of the good. But we do have PAC indexing now. We just added it. I don't think it's in yet, is it?

Or I think it's been added to the working draft, but not in 23. Yeah, it's been added to the working draft. Not not. Yeah. Yeah. It's the working draft. Yeah. Yeah. Yeah. Twenty three. Twenty six. Yeah.

We're going to get a twenty six. Yeah. And that's one of those like minor things that when I train people, I'm like, yeah, and there's all this thing you're probably never going to use it. And I'm like, I use it every day. Like I'm constantly using it and it changed my life. And but it's just a footnote for a lot of people. Well, hopefully we'll be able to get him on.

He can talk to us about some Swift stuff while he's at it. Doug, you probably don't listen, but if somebody that is close to Doug wants to send them this episode, it's a holiday special. So, you know, I'm sure that this will get back to Doug somehow. So Bryce, you may be curious to hear this this so we were talking about how long it takes to do stuff in the committee and something i started working on and i think 2017 2018 something like that so it's five or six years i've been working on it is uh like um unicode support for

c++ standard library right and i at the last meeting i just decided i am sick of working on this i don't care where unicode that much i'm walking away from i'm just abandoning it entirely It's a standard library, right? And at the last meeting, I just decided I am sick of working on this. I don't care where Unicode that much. I'm walking away from it. I'm just abandoning it entirely. But at the same meeting when I decided that, I was mentioned to people. And I did it with this guy, Eddie Nolan. Yes.

You may remember him from the LWG, right? We went to the theater together a week or so ago. And I heard the rest of this. Okay, all right. So he is picking it up and running with it and i'm so happy that it's not going to just get abandoned completely even though i'm the one abandoning it i'm just like sometimes you reach a point where especially with a volunteer thing like you're just so sick of working on it you can't motivate yourself to do it and so i was

at that point yeah yeah but sack sack eddie is a nice guy he's a nice why do i want to throw him under the bus like that human being why do you have to go on nerds night and like this well that's the funny thing is i mentioned that i was i was like yeah i'm i'm disappointed in myself too but i'm just not going to work on it anymore and he was like well i might be interested in picking that i did not ask him i was like i almost i almost thought like i should ask ca Caesar three times to accept the crown. Like I should – now remember, Eddie, I confirmed with you three times that you wanted to do this before you signed up because it's like – it's a lot. It's a lot of work. It's a lot of political stuff.

People have very hard opinions about Unicode and then most people don't know anything about it. That's a weird and troublesome combination. Yeah. Well, he's now, he's now a part of a damn shit's popping lore. So, you know, no turning back now. Yeah. Well, I, I, I, I think that it is, people don't realize the toll that it takes and it is not uncommon for people to decide that they, they just, you know, they got to take a break or they just can't continue with things.

And the problem is when we don't have other people pick things up. And I think that comes back to it before we're a collection of 300 individual authors not a team of working in c++ and in a if we had more of a team culture you wouldn't be driving this thing alone and some of these other people who have strong opinions on unicode instead of just giving their opinions, they would compromise and not only compromise and give you community code, but so often in the committee we have competing proposals and we have people bringing their different ideas, which is good.

But I would like to see more of a collaborative environment where there's less pressure on any individual author to drive a certain thing forward and where people work more and more as teams. Yeah. I get the subtext. It was Corentin's fault. I understand. One of the groups that's been most successful at doing this on the committee has been the

contingent from the US HPC community, in particular from the US National Labs, of which there are about six or I think maybe seven now that participate on the committee. And oftentimes you'll see that their papers have a deep author list. And sometimes the author list will change over time because sometimes if there's one thing like they get together, they talk. And if there's something that is a priority for the community at whole, you know, they find somebody who can drive it. And if somebody no longer has the time to work on it, then somebody else can sort of come and pick it up. And that sort of team mindset is one of the reasons

why we've had so many successful things in the scientific and HPC space in the committee recently. Yeah, I've really been impressed by that same thing, that I see them, they're all working towards, you know, the same goal. No one's across purposes. They're on the same page. They have a variety of things that think are, you know, top priority. And that's natural. But like, at base, they're like trying to reach the same underlying goal, which is really nice, you know, and like, that's why we're getting, you know, linear algebra and like multi multidimensional array stuff,. All that stuff is driven by them and real concrete needs. And I think that stuff is really, really good work. And that includes the SIMD stuff too, right? SIMD stuff came out of a similar crowd. Yeah.

So much of a proposal success on the committee has to do with the merits of the author, not the proposal. To the degree that I can almost tell you just, if you just tell me the name of who's working on a proposal, I can tell you how likely I think it is it's going to get into the standard. And it's solely from like the qualities that make somebody a good champion on the committee is really the ability to accept feedback and compromise and the persistence to do the work. And it's like the people who listen, who learn the culture, who learn sort of the environment of the rooms that they're in and then present their thing and get feedback and really take it to heart and really know how to listen when the room tells them something that they don't want to hear. Those are the folks who can really drive something

through to the end. Yeah. Yeah. I completely agree. There's a lot of people that will stick with something like a bulldog and just won't let go and and i don't mean that in a bad sense i mean like they they're rolling with the punches they're making changes but they want to see it through yeah and then there's some people that like um i don't know i think they're more like uh a gila monster or something they like they they clamp onto something and they're not going to let go but in a bad way like where they're like this is the only way to do this i don't like all these all these counter examples for the way i want to do it like i don't care about them they're

not important like this is the only right way to do this there there's no compromise and that's like that just doesn't fly i think it's a lot of it and this is part of like nvidia's philosophy the committee is we we come to the committee with, with goals and with features that we have in mind, we're never wed to a particular design. And like, I think that this is the bet. Like if your goal is like, I want to see, I want to see C++ support X. Like that's, that's a great, great approach to coming to the committee is like,

I'm going to work on that goal um but if your goal is i want to see this specific design go into c++ well that's that's not necessarily going to be how things are going to go um because it may be that in the course of exploring that design the you learn that there's there's not consensus to do that particular design on the committee. And I think it's orders of magnitude easier to sell the committee on, this is a goal that we agree on, than to sell the committee on, I want this particular design. Yeah. Yeah, there's been a few design elements that I was really fond of

and I had just let go of them and it's kind of heartbreaking, but at the same time, like, uh, that's just, you know, that's just the way it is. Right. I mean, you can't, you can't go into a room of 30 people and say like, it's my way, the highway, they're going to be like, well, there's the highway. Well, it's, um, you know, the process of standardizing something, it's the same process of, of contributing something to an open source project where it is it's all about you giving up control and ownership like yeah you start off with 100 ownership of this thing and then you bring it to another group of people who you want to seek approval from and you slowly lose ownership of it and it becomes something that is communally owned yeah absolutely and that's what you want ultimately

i i am sad that you will not be working on uh on on unicode uh zach but as long as long as you continue coming to library of illusion when i told eddie like you know it's i have i have a lack of motivation to work on it directly but one thing that i have sort of an infinite um amount of of uh reserve energy for is like talking about things that that i've done or that um are i think are important and so you know i told eddie i'm going to be 100 available we already had like we had like a two or three hour call where we're talking about all the details and stuff so i'm very much uh going to support him and everything so hopefully hopefully that's a success,

but I won't be doing it directly anymore. And there's been a bunch of things where I'm like, look, I mean, if you made that decision, I'm going to write a paper saying, I think it should be a different way. But all these other things like, hey, I don't agree with some of them, but it's your thing now.

Like you do it the way you're going to do it. Like, don't let me tell you, like it can't be done that way. That's your thing now. Well, this leads me to an interesting question to ask you, Zach, which is what do you view as your greatest successes on the committee? And like, how do you think that you add value to the committee? I don't know.

So this is, you know, I've had a few conversations along these lines with other people before. But I mean, I think imposter syndrome is kind of like everyone has it. know i've had a few conversations along these lines with other people before but i mean i think imposter syndrome is kind of um like everyone has it and the people that don't are kind of the people that i think are kind of worthless like like if you think if you think like rice doesn't have imposter syndrome yeah well hey look the the comment speaks for itself but but you know what i'm saying like you know like a certain amount of like humility and like i don't know if i'm doing the right thing is required to like sort of you know take feedback and and say like you know if you're 100 concerned i mean not concerned

convinced that you're like doing it the right way and there's no other right way to do it then i think um that's problematic so so to that extent, I think like, I mean, sometimes there's a thing I go through and my wife is very familiar with this because she's the one I talked to about this. But when I'm about to go to a committee meeting, sometimes like, why am I even going to this? I don't know if I should be doing this. It's like a lot of travel. It's a lot of time. And then I get there and I'm like super excited to be there. But on the way there, I'm not always excited to go. And so I think the in-person stuff is really useful. And I feel like I've had a bunch of small contributions that I think are useful over the years.

But I don't think there's any like big thing that I've done that's like, oh, look, you know, like Eric Nebel can point to ranges, right? And along with them, Casey Carter, right? They can say like we did this and that's a, that's a real achievement. I don't think I really have anything like that. But you know, that's fine also. Like I don't, I'm not like looking for like, what's the big thing that I'm gonna make my name with or something. I just like kind of the, the approach that I've taken is, is there something that I think we should have, but we don't have it. And I have the expertise to do that thing. If I, if I can fill that niche of like, I think it should exist, but it doesn't. And I think I, I have the, the wherewithal to do it. Then that, those are the kinds of things I like to work on.

See, see, you've fallen into my trap card here because you're, you're one of the people that, that there's maybe like five or 10 people that during my time as library evolution chair, that I think were the, the, like the, I would call them the regulars, the people who would be in the room who would actively participate in review and really without whom we could not do the work. And you're certainly, you're like in my top tier of, of regular reviewers. And one of the reasons for it is because when you're in the room participating in a review, you're usually quite vocal and thoughtful

in providing feedback. And so I don't have to worry about, it's like somebody reading this, are we thinking about things? You'll voice your opinion. You think about something like ranges. And Eric and Casey put so much work and effort and, you know, years of their lives into it, but those features would not have happened without

the thoughtful review and feedback that they got from the committee. And I think that for people, it's funny that often some of the people who I view as the most valuable on the committee are the people who get the least praise and the least outward glory and who face the greatest imposter syndrome because they're like, oh, what am I doing here? I'm not, you know, I'm not Eric proposing the next big ranges or something. But yet those folks who show up regularly, who actively participate in the review, they have such a huge impact. And it's really, it's like you're a force multiplier because instead of driving one big feature, you are helping shape, you know,

every big feature that comes through. Yeah. Yeah, well, I appreciate that. Thanks. So I wish I had some way to somehow turn this into an insult for Bryce to diffuse the genuineness of this moment, but I can't think of one. But so I think there's a funny thing, because you say it that way. And when I'm in the room doing this, I'm like, am I talking too much? I feel like I'm talking too much. Because I feel like when I have lots of things to say about stuff, and no one else is talking about, I'm like, am I talking too much? I feel like I'm talking too much because I feel like when I have lots of things to say about stuff and no one else is talking about it, I'm like, am I dominating the conversation? Should I shut up? And I do feel like I still jump in when I

think I have something to add. And there's something that is a function of age, I think. I think if I was 20 years younger, I wouldn't be as vocal because a lot of times I'll say something and be like, that's not at all the way that works. I'm like i'm like oh yeah yeah that's completely stupid never mind and but but it rolls right off my back and 20 years ago i would have been like you know that night but like why did i say that you know it's just been like obsessing over it so um so that's part of it too is that even though i sometimes feel like i'm like saying too much then i just keep going if i feel like there's something i don't understand, I feel like probably someone else in the room

does understand it too. Yeah. Well, and one of the main reasons to take a poll in a C++ committee subgroup is because it allows the people who aren't willing to verbally contribute to express their opinion. Yeah. who aren't willing to verbally contribute to express their opinion um yeah and uh you know it's oftentimes 50 or more of the room are um they they don't feel comfortable they

sharing because they're feeling some imposter syndrome they're like i don't know if i you know if this question's you know relevant um uh you know maybe i'm just you know stupid i don't understand it or something like that like a lot of people feel that way um and uh it's really hard like even even in a room of like world experts in c++ it or anything really it's really hard to get people to be comfortable um uh sharing because every person's like well i'm not the world expert here it's everybody else is the world expert you know well that's what you know i've gone out of my way at different times like someone especially someone who's new to the room and they say something that's just like off base because

they didn't they didn't understand something they lost the thread of the conversation i've gone out of my way to say like hey you know like my phrase for this is like uh ignorance is a default state of being like, you didn't know that. But that's fine. None of us were born knowing this stuff. That's like, I say, I say the wrong thing all the time, right? And I will say, I will add that to it. So I feel like, you know, we can do a good job of being really inclusive of people who are newer or just more reticent to speak out, even if they're like a regular, there's some people that show up every meeting, but they almost never say anything. And like you said, I think they're an important part of the process

for the exact reason you just said. Anything that we can do as a group to help people get over that, I think is a good thing. Yeah. I mean, anybody who's spent any amount of time in meetings with me knows this. I am constantly confused. And I am completely shameless. any amount of time in meetings with me knows this i am constantly confused and i have i i am completely shameless um like i i you know if there's something i don't understand i will say

i don't understand it and i'll say like explain it to me and you know like often that is a recurring pattern in my meetings at work where i'll be like no no you're like you need to show me an example like I cannot my mind does not work this way and I can't I can't uh I can't count the number of times that I have with great confidence said a thing at a committee meeting while sharing that was like just like a total misunderstanding I was totally wrong and somebody corrected me and I'm like okay well now I okay you were right i was completely wrong um yeah and i think that's that's my superpower is just that like i'm shameless like i have i have no qualms about uh appearing and being right because it's it's the only way for me to reach understanding is if i tell people like okay, okay, like, I don't get this. Yeah, I mean, you're now like where I am now, but when I was like, you know, your age,

I'm not sure exactly how far apart we are in age, but I was not able to do that. I think if it keeps going like this, you're going to say some truly inappropriate things when you get to be able to, like some really like, oof, can we keep this guy in the payroll after saying that? I think that may be true. So do you do a lot of code reviews at work too?

Yeah, so we have a really tiny team. There used to be a larger team for just a variety of accidental reasons. We have a small team. So the three of us, we code review basically everything together. So like anytime someone pushes a major thing from their local working repo to the GitHub, we always review it. Yeah, so that's like part of the culture here, within my team anyway. Yeah, I mean, how much overlap do you think there is

between like the code review and the committee review process? I imagine there's a good bet. I think, I mean, I think there's a fair amount, except that it's so concrete with a code review that I think it differs that way. There's less philosophical, like, well, what are the follow-on, what are

the knock-on effects of this going to be down the road? I mean, there's definitely some of that. You see something, you're like, oof, this is going to be hard to maintain later, and you make a comment about it. But I work with pretty conscientious people, and we don't really see code like that that much. Whereas there could be things in a proposal where you're like i see what you're trying to do but i think this interface has these potential pitfalls and another comparable interface wouldn't

and so let's talk about that so i think that the the style of review the kind of things i'm looking for are very different i'm looking for like factual errors in the code when i'm looking at code review at work whereas i'm looking for more philosophical like there is no ground truth but could we do better in uh in committee stuff so it is different but i don't think it's fundamentally different but what about like design reviews at work or like architectural decision making like do you do any of like that that sort of stuff and is that how similar is that well so we do that and that's that's a good point but we don't so we do that and that's a good point,

but we don't, when we do that, that's not a code review. Usually we're having meetings and we're coming up with like a rough sketch of like, this is how we think things should go. And then we review kind of on the fly. So like, for instance, recently we implemented this GQL data model. And for people who don't know what GQL is, I was learning about it myself. GQL is this format for having a data model that can be easily back-ended with like a database or like you can read from a flat file or whatever. And you can always change the back-end later on and the front-end GQL data model stays the same. So people usually use GQL in like web technology and other things like this, where you run like all the data formats essentially are JSON I think by default so so we had to come up with like a front

end for the data model like what do the data look like how do the queries look that was amenable to an efficient implementation on the back end but there were multiple kinds of searches and queries of data you wanted to do and so we had had to have that discussion about what do the data need to look like at the API level so that we can write all these efficient backends and then have room to change them out with other backends later on if we decide to do that. So that's the kind of big architectural thing where you have questions like, does this limit us in the future? What are the tradeoffs? That kind of thing. So that kind of thing is very much like the same kind of review we do in the committee. But that just tends not to be a code review. So we have this culture of code reviews in the form of PRs, but then

the big architectural stuff tends not to be like that. It tends to be more of a design meeting kind of thing. Wait, would you have any advice to people that are seeking to become better reviewers of in any shape? Like what's your what's your secret? Well, I think so. This is a question that I heard someone at C++ Now ask Eric Niebler when I was right there. And I've had part of the answer that I gave myself. But the question was, how do I become a good library writer like you know and this is something I've actually specialized in my career I'm like like I'm a library person like first and foremost and but that's that's a rare thing like people

don't usually specialize in libraries for whatever reason and Eric said something somewhat similar to this, but my take on that answer is read lots of library code and do things along the lines of, like, when I sit down to write a library, the first thing I want to do is write, like, the use of the library, not any code or design or anything like notes about how the library should work. So the idea is, as a user of the library, I want my code to look like this nice, beautiful thing that is, you know, the ideal. And then maybe when you're implementing the library, you can't quite get there for some technical reason you can't have that interface that you started with but maybe you can find another way to have like a very graceful kind of thing to work with so i think essentially a good review of high-level design and a good design of a library are isomorphic in that you want lots of things to be the same about them right like if it's possible to do so you want to make it impossible to use it incorrectly if that's not possible to make it difficult to use incorrectly you want to not violate the principle of the surprise when you return something it

should be the kind of thing you would expect from a function with that name to return blah blah blah there's a bunch of them that people are familiar with. And so the way you get there, I think, is iteration, right? You design interfaces or high-level things, and then you see how it works, and then you just do it and do it and do it, and eventually you develop good taste, right? I feel like I have good taste now, and I feel like I started with awful taste, and I had to sort of get there by making mistakes over and over again. So I really think it's a question of doing it and then seeing what works and seeing what doesn't. And you can short circuit some of that doing it yourself by just reading other people's APIs and large level architecture things and understanding why they work and what the trends are. And then more examples is another way of getting reps. I definitely feel like I've learned a lot about what good design looks like from witnessing bad design or doing bad design and then spending years paying the consequences of the bad design.

Yes. Yeah. And I think, you know, there's I have what I consider to be a superpower, which is that when I hear good advice, I recognize as good advice the first time I hear it a large percentage of the time. And what I've discovered is that that's just not what other people are doing. Like, I didn't realize this was a superpower until I got experienced enough to see people getting very good advice and ignoring it before I realized, like, oh, this is like a thing that I'm particularly good at. I had no idea it was a thing to be good at. But so like when someone says when you do it like this, this is the problem, we do it like that, this is the other problem, that's really good advice. That is hard won knowledge that someone with the experience you just described where they did it and they had to live with the consequences of it. And when you hear that, you should internalize that as if you did it yourself

to the extent that you're able to do that. I think that's a big part of the process. Because if you pay for every mistake you make, that's great and you'll learn that way, but you should try to short-circuit that to the extent you can. Yeah. Hey, that's enough, babe. I'm sorry, but I mean, I was just answering what you asked me I don't think you should call me babe it was inappropriate

I somebody said this to me earlier in my career that like the mark of a really smart person is the speed with which they change their opinion when convinced that they were wrong. That like somebody who's like a really, really, really smart person,

like you show them in some way that they were wrong and then just like, boom, like 180. They're like in the completely opposite direction. Yeah. Well, I think that's true, but I think there's also some maturity that comes into play there too because like if you're just like really like self-conscious and kind of a raw nerve all the time, some people just double down on something when they know it's wrong because they just can't stand to be wrong. Do you know what I mean? Yeah.

They see what you're saying and they refuse to acknowledge it because they – so there has there has to be some temperament in there too but i think that's generally true like um you've uh maybe read thinking fast and slow this danny kahneman book it's a fantastic book oh it's so good i have basically sorry you have or have not connor i have yeah i'm a big uh behavioral economics you know pop science fan yeah me too i really love it so this is a book that about every uh 10 to 15 pages, I was like, oh, that's why my brain works that way. I mean, it's really like a user manual for your head. It's really great. But it's based on work done by one of the author, who was Danny Kahneman and his partner in crime, this guy named Amos Tversky. And Danny Kahneman

writes, not in Thinking Fast and Slow, but in another book about their collaboration, he writes this thing that amongst people that knew Amos Tversky, there was this agreement that the best IQ test in the world was how long it took you to realize Amos Tversky was smarter than you. And if you just got it immediately, you were amongst the brightest. And Amos Tversky was above you but but you knew where you were um and i think uh i think that's really fascinating that there's there's something like similar about that you know like can you can you recognize your own failings and how quickly yeah yeah i definitely feel like that's something that i'm i'm pretty good at. Although, I don't know. I still retain stubbornness at some points. Yeah, yeah.

We probably should start wrapping up because I got to prepare for the arrival of the Polish relatives. And I do need to board my flight in like 10 minutes. Wait, Connor. Wait, wait, wait. Boarding starts in 10 minutes or my flight in like 10 minutes. Wait, Connor. Wait, wait, wait. Boarding starts in 10 minutes or the plane leaves in 10 minutes? No, no. Boarding officially starts in 17 minutes at 12.05 Pacific time. So I do have to get to the gate, though, which is on the other side of the airport, which is why.

You fly in Air Canada, home? And I think actually at one point I was going to mention which we can mention it now is that yes i'm in san diego you're in austin uh zach and then bryce is in new york so we're coast to coast uh yeah probably the first first time it's an a220 300 you want the tail number? Jesus Christ. Oh, Bryce. I really hope that the audio is going to be fine, because if you didn't record locally for the first bit, that means we're going to have to use the audio from this meeting. You were muted for pretty much that whole time.

Not at the beginning, though. So anyway, hopefully it'll be fine. And this is the holiday gift to the listeners that I'm pretty sure we're just going to release this all in one go. So this is going to set the record for the longest episode by a long shot. And of course, now I've dropped from the meeting again, but I think Bryce and Zach can probably still hear what I'm saying. Anyways, this has been absolutely amazing. High-low, rust, bleeding-edge C++, elements of programming, committee stuff. You know, the listener is going to be having a very enjoyable holiday season thanks to,

and most importantly, ah, damn, shit's popping. I like how that just doesn't sound like it goes with hosted by Bryce and Connor. It just doesn't go together somehow. Quick, quick, end the podcast now. We shouldn't have started talking about travel. It's going to be another hour and I'm going to miss my flight. We're going to have to wrap up. This also has a much smaller demographic that's interested in hearing your guys' travel complaints.

All right. Well, thank you all. It's been fun. Yeah, thanks, Zach. This was a blast. Yeah, thanks for having me. Merry Christmas. Be sure to check your show notes in your podcast app or at ADSPthepodcast.com for links to any of the topics we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. If you made it this far, consider sharing with a friend or your followers on whichever social media platform you prefer, whether that's Twitter, LinkedIn, or another, as this was a lot of work to edit. But we appreciate all of our listeners and thought we'd do something special because people are constantly requesting that we don't slice and dice these up the way that we typically do. Anyways, thanks for listening. We hope you enjoyed and have a great holiday season. Low quality, high quantity. That is the

tagline of our podcast. It's not the tagline. Our tagline is chaos with sprinkles of information.