Algorithms + Data Structures = Programs - Episode 114: Rust, Val, Carbon, ChatGPT & Errors with Barry Revzin!

Episode Date: January 27, 2023

In this episode, Conor and Bryce talk to Barry Revzin about Rust, Val, Carbon, ChatGPT, error propagation in C++26 and more!Link to Episode 114 on WebsiteTwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the GuestBarry Revzin is a senior C++ developer at Jump Trading in Chicago. After programming for many years, he got really into the nuances and intricacies of C++ by being unreasonably active on StackOverflow (where he is the top contributor in C++14, C++17, and C++20). He is also a C++ committee member, having written dozens of papers for C++20 and C++23.Show NotesDate Recorded: 2023-01-15Date Released: 2023-01-27ADSP Episode 113: The C++26 Pipeline Operator with Barry Revzin!P2011 A pipeline-rewrite operatorP2672 Exploring the Design Space for a Pipeline OperatorRust Programming LanguageRust TraitsSwift ProtocolsRust std::iter::IteratorRust The Cargo BookVal Programming LanguageCarbon Programming LanguageCarbon Operator PrecendenceEpochs: a backward-compatible language evolution mechanismADSP Episode 97: C++ vs Carbon vs Circle vs CppFront with Sean BaxterCircle CompilerChatGPT: Optimizing Language Models for DialogueGPTDuckOxide and Friends PodcastBryan Cantrill on TwitterBryan Cantrill: The Summer of RUSTOn The Metal PodcastOxide and Friends: NeXT, Objective-C, and contrasting historiesElixir DocsRust DocsP2561 An error propagation operatorSy Brand’s tl::expectedP0798R4 - Monadic operations for std::optionalC++23 std::expectedChicago C++ Meetup: Defining Range Formatting

But I think if anything, maybe even the more compelling side is like all the tooling around it. Obviously, it's nice when you're just like a newer language, right? Like Rust has the benefit of being like 30 years newer than C++. So as far as the other languages go, the one that I find the most interesting is actually VALC. Welcome to ADSB The Podcast, episode 114, recorded on January 15th, 2023. My name is Connor, and today with my co-host Bryce, we interview Barry Revzin and talk about Rust, Val, Carbon, and the C++26 error propagation proposal. And maybe we'll turn this into like a mini Rust episode, because we're in our Rust phase of our podcast. We've temporarily turned into a Rust podcast,

kind of. And at the tail end of this paper, you mention sort of offhandedly that this would all not be necessary if we had something like Rust traits or Swift protocols. And one, I wanted to get your thoughts on why, well, is that the case for everything? Like for instance, a zip transform, like could you implement a zip transform where you're doing sort of the piping twice? Is that possible in the Rust traits or Swift protocols? And also too, when you finish answering that question,

thoughts on Rust, are you a Rust expert secretly? Because you've done a talk where 33% of it was on Rust and you make references to Rust. So yeah, two questions there, both about Rust and Swift if you want. Yeah. So no, traits and protocols wouldn't subsume every possible use case of pipelining with placeholder. They would subsume every possible use case of pipelining with placeholder. They would subsume every possible use case of pipelining without placeholder, because that's basically what they do very well. So if you look at what Rust iterator is, this is basically a collection of functions that you can call with regular dot syntax. And that does what we think of as piping. It just works.

Again, there's no library machinery there that just works in Python language. But that is the left-threading model of placeholders, if you will. So if you want to do anything that isn't that, that's not going to help you at all. It's not going to help you pipe into the second parameter. It's not going to help you pipe multiple times. It's not going to help if the thing. It's not going to help you pipe into the second parameter. It's not going to help you pipe multiple times. It's not going to help if the thing you want to pipe into isn't a function call, because it's just function calls. So similarly, this is like,

will unified function call syntax be a solution to this? Well, one of the problems is, well, some of these things are objects and some of these things are functions and you want to deal with like this weird overload or loosen between things that we don't really have before and you find function calls syntax has its own set of problems. And so I don't know. I mean, personally, I think rasterized are really nice and I would love to have something like that in the language. And if we had that, then the question is like, well, would the additional value of placeholders

still be worth pursuing? It would certainly be a much smaller problem. And I don't know that it would end up being as compelling. But given that we don't have anything like that, then the set of problems that this would address becomes a lot larger. And so I think it's a much more motivating feature as a result. Am I a Rust expert? No, definitely not. I have written maybe a few thousand lines of Rust code at this point,

mostly for solving advent of code problems, but not anything real in any sense. I just find the language interesting, and I just like learning things about it. And I know even less about swift uh the the extent of my knowledge of swift is like reading random docs and like asking data frames questions on occasion all right well while we're talking about uh um rust any thoughts on the general i mean we've i asked jason this when he was on so I'm not sure if we've asked every guest since sort of this has happened

but the whole Carbon Circle Rust, CPP2 thoughts on this whole you know the Empire Strikes Back year of 2023. So for Rust specifically so there's two things that two broad things that I think are super compelling about Rust

one is of course like there's a lot of nice things in the language that just like make a nicer program with like the whole, the whole bar checker thing, trades, like there's a lot of just like nice things. A lot of the syntax is terse in a way that I think is a little jarring when you first come into, but then once you start, once you like deal with it enough, and I'm hardly an expert, but it's like,

but I already feel like I'm past the enough stage. The fact that things are tererser is just nice. The fact that functions are just FN and the fact that you have I32 and U64 for all your types instead of having to write out all this stuff is just a nice quality of life thing. But I think if anything, maybe even the more compelling side is all the tooling around it. Obviously, it's nice when you're just like a newer language right like russ has the benefit of being like 30 years newer than c++ and so there's a there's a lot of stuff that's changed in like the wide world of programming um from 1980 to 2010 i don't remember exactly when russ was first created or um somewhere around 2010

give or take a few years and so um i had a coworker recently, John Shaw, who gave a talk to us about this project that he's working on for actual work in Rust. And this guy's a great C++ programmer. And he's always been kind of like a Rust evangelist, but this is the first time he's actually done real things for a while. And this project's like, I don't know, 50, 100,000 lines of code. It's like a real thing. And most of the stuff that he's talking about was like the tooling

environment. The fact that stuff just works is super nice. If you want to rename a variable in your IDE, that just works. This is something that has never worked for me in C++ in any IDE that I've tried. Even if I'm renaming

a local variable in a function that's only used in that function, it just never works. It always takes forever. It's always broken. We have all these other issues with build and dependency stuff. And sure, when you start doing especially complicated things, Cargo kind of breaks down. And I've heard a lot of people complain about it, especially if you're doing cross-language stuff. But there's a lot of stuff in Cargo that's just really easy. There's a lot of tooling that's built on Rust that's just really easy in a way that is just not for us.

And if anything, that was the part that was most saddening about me. If I could get all the tool ability but stay in C++, I'd probably be a lot happier. So as far as the other languages go, I don't know. The one that I find the most interesting is actually Val I have no idea

how Val is supposed to be backwards compatible with C++ it seems like a completely different language model wait that's a guarantee that Val's making? I don't think it is I think that Val is an experimental language and does not

my understanding was that there's no intention that val be backwards compatible or that val necessarily be a uh you know a production grade language that it's meant to be an experiment uh something that uh you know maybe other languages will learn from maybe that will grow with time that was just i do think i do think it was intended to be interoperable oh backwards compatible paddle was probably the wrong word i just submit the website yeah it's the the number four thing is it says interoperable with c++ programming languages rarely survive in a vacuum val aims to take advantage of the vast software capital of c++ by supporting full interoperability so i have no idea how that's supposed to work because the

model in val seems to be very different than the C++ model. But there's a lot of cool stuff about it that I find pretty appealing. Some that we might even want to consider trying to see to what extent we can pull into C++. Some of the other ones, I guess, I just don't get. Maybe this is just one of those things that I just don't understand. I don't understand carbon, just kind of fundamentally. I don't understand the selling point. Because one of the big things that people are talking about these days is

a lot of stuff about safety, right? How safety is important. And that's one of the major selling points of Rust is that you have a lot of things that are just compile errors instead of figure out how to run sanitizer to cache the same kind of errors. But my carbon doesn't answer that.

Or at least it had no answer to that question the last time I looked at it. And so when I look at it, there's a lot of things about there that are nice. It's a nicer syntax. It has some nicer language features. It's going with the trade approach of customization, which is, I think, the right approach. And that's nice.

One of the small things in there that I really liked was the operator precedence model that they had. I don't know if you guys looked at that. Yeah, it's that flowchart diagram. The fact that operator precedence is in a total order, I think that's a very cool way of doing it. That's probably the right approach. I don't think I've

seen other languages do it that way, which in retrospect I find kind of surprising. Everyone tries to define some total order on operators, but sometimes there's no obvious precedence. Um, so they just don't define one and make it all formed. I think that's pretty cool. Um, but other than that, like, I don't, I don't know why I would use it, I guess. Yeah. I think their, their pitch is that they're hoping it's, you know, the, the

Kotlin is to Java, what carbon will be to C plus plus. C++. And I think if they deliver on their goal of hitting a button that can... I'm not sure if you've seen any of the Google I.O. talks back a few years ago when they were promoting Kotlin from a silver language to a golden language or whatever terminology Google uses. They had these demos where they would show you this 60 lines of Java code and you click a button and it turns it into three lines of Kotlin and it was all automatically like converted. If they deliver on that promise of being able

to sort of migrate your C++ code to Carbon code, I think that's compelling. The question is, is that something that's actually gonna be possible? Or is that something that's actually going to be possible? Or is it like, well, if you are in the sandbox of C++ and you stay in that sandbox, we can convert your code. But if you start using features that aren't... Because that's sort of my big question is, if you're going to create a new language, how do you map? How do you have feature parity when you're completely changing certain things but hey google's google so

uh we'll wait and see yeah like so one of the things that i think is kind of important for us that you know we kind of briefly have discussed on occasion but like really kind of dropped the ball on and should come back on is this notion of well like so like like what we see in carbon what we see in cpp2 is that you know there there are changes that we want to make to C++ that, you know, I think people wildly agree that these are changes worth making. But that we can't make in C++ because of source compatibility, right? We have this strong promise of, well, if you compile your code with today, that'll do the same thing with C++ tomorrow and C++ the day after that, right? And when that doesn't end up being true, like, we try very hard that, like, well, it's not

true because, like, your code sucks and is bad. And so if it doesn't compile, that's probably a good thing. So you should rewrite it. But sometimes ends up, like, with the comparison operators stuff in C++20 where like a lot of your code is just randomly broken and you have to rewrite it even though it worked totally fine before. And that sucks. And I think that's like wildly considered to be a mistake.

Like whenever we do stuff like that. But imagine we live in a world where like we could make breaking source changes in a way that didn't actually break code um so this was you know vittorio um romeo had this proposal which he called epox for some reason but i'm just going to refer to as additions well you know why because uh rust additions were initially called epox and then they changed they changed it at the 12th hour because uh i can't remember there was maybe ambiguity in the pronunciation and like some people were anyways, they changed it to additions for marketing reasons. I think

it's a much better name anyway, because epoch is already a thing. And like when you, when you talk about time and clock, um, so it's nice to have a distinct word. Uh, yeah. Yeah. So like, you know, imagine if, you know, at the top of your, and modules provide like a good boundary for that, like Victoria made this point, there's a different paper from nathan myers that also kind of made this point of like um well like modules offer us like a nice opportunity to introduce uh these like notions of code that aren't just like header textual inclusion um and we could take advantage of that to make advancements and so like if we if that was something that we made concerted effort on

and we had this model of like breaking source compatibility and making changes to the language that like old code would continue to work but like new code could be improved like how many of the problems that these uh successor languages are

trying to solve could just be could just be c++ um certainly like any syntax changes we could just make because it's just syntax the semantic ones are kind of harder but i think it's something that we could think about yeah this is almost a very very. I'm not sure if you listened to that episode with Sean Baxter, is that he basically made a similar point that, you know, we are a committee of folks that, or do you know what the because the vittorio's paper went to i can't remember if it was evolution working group incubator but it like it got shut down at some point do you know what the reason like reasons for that were well i don't i don't know about shut down i think that's probably the wrong phrase so well one of one of the issues is that there's a you can't necessarily do anything on an addition boundary. And there are issues that you have to work through.

So one of the examples that he had in his paper for like, this is something that we could change in a language. It's like implicit conversions between int and float, for instance. Today, int is implicitly convertible float. Maybe tomorrow we want to make it only explicitly convertible to float. And so one of the issues with those kinds of rules is that you have to answer the question of, what are actually the rules on module boundaries, on addition boundaries, between code that has different semantics? Or the most extreme version is like, well, I have three different modules

and one has a function template that uses a concept declared in another one that uses a type declared in a third one. How do you know which rule set to use when these things interact? And so that question isn't answered in the paper right now. But, like, that question could be answered. There are probably reasonable answers to that question.

And one of the reasonable answers to that question might be that, well, maybe we just can't make these sorts of semantic changes. And we have to limit ourselves to making, like, syntactic ones. But even if that's the answer, which I'm not sure that it necessarily is, but I haven't really thought about this problem at length, there are still a fairly significant amount of syntactic changes that we could make that would have a lot of value. Even if like, just like removing typedef or or silly things like changing changing the type of string literal for some from something that is terrible to something that's useful um is almost certainly a change that that we could make um that would be that would be like a nice thing to do and these are the kinds of changes like well we can't make we can't like change the type of a string literal today because like there's a tremendous amount of code that depends on the

type of string literal being what it is uh but if i have new code that wants to opt into the new rules maybe we could and then suddenly rangers algorithms could just work with string literals instead of just being horribly broken or best case not compiling uh that would be that would be a nice feature well sounds like you've got a paper that you can add to your list of tens and tens of papers. Do you know how many papers you've written? Because I know you have a GitHub repository. No, I have no idea. And I don't know the numbers to any of my papers.

So there's too many of them. Yeah, that's fair. I mean, as Bryce mentioned, Empire Strikes Back, 2023. I also, I was trying to explain this to a friend that doesn't understand star wars and they were completely confused because i thought it was just a wonderful analogy um that uh 2022 was a new hope and uh all this yeah my girlfriend was also did not think it was that great but she hasn't watched star wars so who's the empire in this analogy c++ okay the c++ committee and the c it's that last year was a new hope all all the all the rebel languages popped up and now um now uh the empire is gonna come uh storm their

base on home so that we're just gonna like murder people is that is that what we're doing now i don't know if i'm on board of this metaphor no but i will say that the c++ committee that the atat is definitely something that the c++ committee would design like that that was definitely a vehicle does like that that it should have been like it should have had wheels and said they gave it legs. And it has a turret on the head, but very limited firing radius. That was definitely designed by... I don't know. I think it's way too close to being a pronounceable acronym

for something to come out of C++. That is a good point. One thing about that analogy that I'm not sure if you're sitting on this and you're waiting for 50 episodes to go by till next year's retro and predictions for uh 2024 but uh my my theory is that you know you think 2023 is the empire strikes back and that 2024 was going to be return of the jedi where one of the successor languages uh you know prevails the question is which successor language is luke skywalker uh you know is it rust is it val we gotta i mean i i think conservatively speaking you gotta bet

on rust um just because it's got the most momentum behind it and like i almost any other merit in the software world. Like, you know, one of the reasons why C++ has been around and has been successful so long is momentum. And one of the things that keeps C++ going is momentum. And one of the reasons why I'm typically skeptical about successor projects and things that try to, sort of doing a rewrite or starting from scratch is that they don't initially have momentum. And that makes them, even if they're 10x better on a variety of technical merits, without momentum, the odds are against you.

But Rust now has the momentum behind it and it's also got, you know, lots of technical merits. And I think these things sort of start to snowball. Once you build enough of a community, once you have enough, once you're in enough places, then it just becomes easier and easier for your technology to be adopted and it'll grow more popular,

you know, even more rapidly. And so I think out of all the successor languages that we've talked about in this podcast i think rust is the one that's um most likely to take over the world um simply because it's been around longer and it's got more momentum yeah it'll be i'm this the next couple years is going to be very exciting for podcast hosts and i mean just people in the systems programming language space even if you don't have a podcast, but we get to ask folks about this and it's super interesting to hear people's thoughts. But yeah, like it is, uh, it's like you were talking about your coworker, Barry, the biggest

thing that like impacts how I write code in that language is that everything just like comes out of the box. The equivalents in C++, you know, Clang format, Rust format's just there, you know, static analyzers, Clang tidy, Rust format's just there, you know, static analyzers, Clangtidy, Clippy's right there. Just everything just works so nicely, you know, cargo package management, I want to pull something down, super easy, you know, where I got to go choose a build system in C++ and heaven forbid, I mean, this is one thing that I've been talking about, chat GPT. If you can point chat GPT at a GitHub repository, and there is a website that

my buddy showed me, it's called gptduck.com, I think. You have to sign up for it and it may even cost money, but you can point it at a GitHub repo. And if you can ask chat GPT to set up a CMake file and then say, I want CMake and go get me these packages. I want range V3, this, this, and that, and it can just go do all the build stuff. Sign me up. I will say that. So, so the same car for John. So we're recently like setting up our internal compilers for instance, at jump with like a bunch of our own libraries and stuff. And we had to like set it up on Kubernetes, which is something like neither of us know anything about except for the, like, that is a word that exists um and he just like asked chat gpt how to do it and that got him like 95 of the way there wow it was just like and he just like typed in whatever commands it told him to run

and and it was running um that's like that is actually like pretty pretty crazy like that if that's the kind of thing that i think that people are asking is this going to change the world you know put us out of business but like there's a ton of stuff that as devs we do that's like just jumping through hoops you know trying to spin something up or and it's not that we don't know what we're doing we just don't you know how often am i a build engineer i'm not a build engineer like some people they know c make inside out we've got a uh a guy on the rapids, Robert, who's like used to work at Kitware. Is that the company that does CMake? Yes. And, you know, he's like a, he's a guru, you know, he can, he's like Harry Potter with, you know, CMake files, you know, you ask him to do something and he'll say the Avada Kedavra, you know, kill a, you know, a wizard.

I feel like the character for who knows what they're Doing is clearly Hermione in that series. All right, Hermione. That's true. She was the spellcaster and the one that Dumbledore entrusted that little time thing in the third book. Boy, you really don't know your Harry Potter that well. I've read them three, not three times, twice. But it's like we're old now.

We were back in high school when we read those books. Anyways, yeah, ChatGPT, if it can do that stuff for us, that'd be fantastic. I mean, it might very well be the future of documentation, right? That's what, oh yeah, this is a great segue because I knew I was going to forget this because we were having you on. One of my new favorite podcasts,

and I'll tie this back into documentation. You'll see why I'm going on this digression, is Oxide and Friends. So one of my favorite speakers alongside Barry, of course, is Brian Cantrell, who I'm probably sure like 25% of our listeners know who they are. He works at a company called Oxide, which is building some sort of low level operating system in Rust, I think, for like embedded devices. That could be a completely inaccurate description of what he does. But he is one of my favorite speakers because he's so energetic. Like one time he gave this talk called Rust Over the Summer and no slides.

And like it's an hour and a half talk, I think, or two-hour talk. Like halfway through, he hasn't even mentioned Rust. He's just going on all these, it's anyways, incredibly entertaining. And he has another podcast called On The Metal, but it's only like 10 episodes. But over the last couple of years, they started, I don't think it's on Twitter spaces anymore. It's on Discord. They, him and a couple of his, you know, people that he works with, and then anyone else that wants to join would just basically hop on a Twitter spaces and record it. And I started listening to it and I've gone back and I'm like at episode six or seven

in the backlog. Absolutely fantastic. Like the most recent one I listened to, they were talking about a book called Steve Jobs and the next big thing next being a pun for the company that he worked at. And apparently it talks about not just like that chapter, but like the early days of Sun Microsystems where Brian and a couple of his colleagues used to work. And they talk about Objective-C, Objective-C++, Swift, Rust. And anyways, just fantastic.

On one of the most recent episodes, they said that like ChatGPT, if it can basically go and just write docs, like you pointed at a GitHub repository and say, please go write the documentation for this. Like that would all, like that's, that is a something where it's not someone being put out of business. It's like, we don't even have time to write docs right now. It's just like you getting someone to do work for you. Anyways, go check that podcast out. It has like way less subscribers than it should have. It's, it's, it's so good. Anyways, that's my little digression. Doc, docs are hard. It's really hard to write good docs.

Yeah. And, and good documentation when it is written well and it's good. It's, it's like game changing. Um, sometimes I go to languages that have really good docs, even when I want to like learn about a different language. But if I know the equivalently named thing in that language, I'll just go to that language. Cause like, it's like they have better docs, like Elixir, um um and their hex stuff uh amazing documentation um shout out to the folks that do that so again again another tooling thing it's like rust doc is really nice and everyone just uses it because it works yep yeah it's uh there's yeah there's so many things but yes will rust be luke skyworker we don't know we've only got 13 minutes left i'm

not sure people have hard stops i know you uh well i gotta go to the opera where are you going to see um it's at this uh this festival called prototype festival so it's all like premieres of uh modern uh opera and uh we saw two yesterday that were really good there was a double bill from this uh irish composer um and the one we're seeing today i think it's called in our daughter's eyes which is uh i think it's a one-man show um about a father uh reflecting upon whether or not his daughter will be proud of him um yeah the one yesterday was uh was one of the two shows we saw yesterday was really really good it's called trade it's um about um

two gay men in uh northern ireland or in no in like northern dublin um and uh it was just it was really powerful um yeah we had a great time yeah it's it's very it's very it was very interesting though because the the language um and the uh the operatic style were sort of a little bit of a clash because it was like very um working class and uh gritty but then they're like you know they're they're opera singers all right okay so we do gotta we do have to wrap this up then in the next 10 or 11 minutes. Error propagation, or if you want to highlight some other paper, I guess maybe you want to give an overview. Let me get the number. The number is an error propagation, 2-5-6-1. R1, it looks like. Yeah. I mean, this got briefly mentioned on one of the other C++ podcasts, but they didn't really talk

about it much. They just said, what is this? So Barry, how about you tell us? I saw that clip. That was pretty sad. I was just like, okay, cool guys. Yeah. So the idea here is that, so C++ has a lot of different error handling models, and that's just a statement of fact. I'm not trying to dive into saying that you should use X or Y model because it's better or whatever. But the other true statement is that exceptions have a lot of language support. And of course, because it's a language feature. And that makes exceptions really nice and ergonomic to use in a lot of ways. Because you just let the errors propagate and there's zero syntax that you have to write to do so. And so that's really the advantage of exceptions is that there's zero syntax to propagating exceptions.

There's zero syntax to writing error neutral functions. It has a lot of really nice benefits. That zero syntax is also one of the big reasons that people don't like exceptions, is the invisibility of error handling. And that's a fundamental thing I'm not going to get into, which one's correct. But in the meantime, a lot of people in a lot of different contexts, and sometimes people that use exceptions for some kind of errors and don't use exceptions for other kinds of errors use types like expected to do their error handling. And the problem with using expected for error handling is that it's very syntax heavy because you do have to manually do this like if if not x, return x.error kind of thing. And in addition to being very tedious to type, it's very error prone.

It's very easy to write something that's inefficient. And part of the heaviness of the syntax around it is why a lot of people use macros for this. You use them to do the unwrap or return pattern is very common to see macros for this sort of thing. But the macros have their own problems because you have to deal with things like lifetime issues and where you're going to construct this stuff. And they're also a little bit limited and they rely upon the really nice version of the macro that lets you write like auto x equals unwrap or return y which is nice because you get this you still get like a real looking variable declaration syntax that relies on like the statement expression extension of gcc which doesn't do copy elision or move elision or whatever so it doesn't actually support moving so even in cases where it should

so it's kind of like a weird state of affairs that we have where a lot of people have used the same pattern, but like, it's not like blessed in any way by the, by the standard. And now, now that we have expected in 23, I expect more people will use this.

Cause I mean, that's kind of the point of standardizing it. Right. And so it would be nice to have like much better tools for handling this sort of thing um and so what what the paper basically is doing is like well let's take this thing that everyone has to write or already writes or already writes a macro for um and kind of elevate it into a language feature that does this unwrap or return pattern. And that language feature of course has to take syntax, but we can make it take as little syntax as possible and make it customizable as a trait that says how to do that. And then this has

a bunch of advantages. One is that, of course, you can do it. And it's very syntactically light compared to any alternative that you can do, even compared to the macro. And we can then use that in other contexts and algorithms as a way of doing short-circuiting. Because I think some of the names in the paper

are still kind of wrong. It's still called error propagation, but it's not really necessarily about errors. It should probably be named more along the lines of control flow. Because Rust does this now where

the new pattern for what their question mark operator does is the names aren't called like error or value they're called break and continue so like either you know you're continuing and here's the value that you're continuing with or you're breaking and here's the value that you're breaking with and so different contexts will use those things as appropriate so in the typical case where I just have a function that wants to like error or return with this error, like I'm breaking out of the function with that value.

But then let's say we want to implement a fold. One of the algorithms that you might want to implement as a fold is like a fold that stops at some point, right? It doesn't consume the whole input range. It consumes until something happens and then returns a value. And that algorithm isn't one that I added in the fold paper, largely on the basis that we don't have a good way of like, well, how do you do the short circuiting? Like what is the shape of that algorithm? And having this kind of like continuation traits thing is like, well, that's the thing

I use, right? Like if you have a short-circuit and fold and like your function returns something that is like an error continuation type. And so if that thing is an error, which is why error is kind of a bad name, if that thing is an error then you return with that thing. And if it's a value then you continue with that value. Does that make sense? It makes more sense in code. It's kind of hard to explain verbally, I think. But that's the idea. One of the problems with C++ is that we can't just use question mark, which is what Rust uses, because that ends up being ambiguous with our conditional operator. So what I'm suggesting

in the paper is two question marks, because that one isn't ambiguous with anything. That one has this problem that there are a bunch of other languages that have a double question mark operator. And for those languages, double question mark always means this one particular thing, which is very different than what I'm using it for. And different, but also like would be potentially useful for us, which is one of the problems with like choosing syntax for anything. So I'm not really sure what what the right answer there is necessarily um but it was pretty favorable to be received in kona so i should probably go ahead and try to implement this yeah this would be it would be very nice um because for folk i mean i basically used i used to use tartan llamas aka uh cybrands tl expected but i think stood expected at least at GCC I can't remember

which one but I remember seeing it on a feature list it's been implemented even though it's a 23 feature although I haven't upgraded the code bases but anyways I've always used expected because I just I like the model better and having not having something like this, that pattern is just, it's ubiquitous, ubiquitous. It's everywhere. Um, and it's not, it's not the end of the world, but having something that basically automagically does that for you would be super, super nice. And the examples that you show in the paper are extremely motivating for those that didn't follow Barry's explanation. Just check the links in the show notes, go to the paper, and just like find the first couple examples because it's similar to Cybrand's monadic interface. I can't remember the name of the paper is, but like the monadic pattern on optional.

And I think, I'm not sure if there's a paper for the same kind of stuff on expected or it already comes comes with it. But those like those examples, when you see them, they're just so motivating for, you know, I think it's involves a cat, and they're trying to get some, you know, food or something like that, or you're putting a bowtie on a cat, etc, adding a rainbow. And you know, the before and after code, it's just, I don't know how anyone can look at that and say that the after code is less readable, like it's so much nicer. Yeah, so expected does have the monadic operators those are already adopted um so those are those are in for 23 the so those operate those functions are really nice and they're really useful um but they're still a kind of a poor substitute for having this kind of value or error operation um because like one so

something and that is probably the most common one that I use in our codebase. And that's great if what you want to do is I have an expected T comma E, and then I have a function that takes an E and returns an expected U comma E, and I have another function that takes a U and returns an expected V comma E. I'm just chaining these operations together. And there's a lot of cases for which that's true, like we use and then a lot in our codebase for our implementation of this. But then there's a lot of other kinds of things where instead of having this dependent sequence of operations, you have an independent sequence of operations. These are actually all the examples that I have in the, in the error, uh, paper. Um, so if I, if I call one function that gives me an expected to E and then I call another

function that also gives me an expected to E, and then I do some operation on the two T's, um, I could use and then for that, but then that ends up being very awkward because like, I'm not really using the result of the first operation to call the second operation i'm just like holding on to it as like a lambda capture and then like somewhere in the inner lambda i'm now using both both t's um so it doesn't it doesn't work very well and that that pattern is also pretty pretty common like i'm just like i need i need five values they can all fail um and then once I get all five of them, then I use them to produce a new value, right? And so like nesting that with n-then is terrible. But if I could not do any nesting,

that reads very well. Yeah. Yeah. Check the paper for examples because it's super motivating. And you said in Kona, this was well-received. So sounds like if everything goes according to plan, we can get Pipeline with Placeholder and we can get the double question mark

or some version of this operator. And we'll be that much closer. Although Rust doesn't have a Pipeline operator. I guess, like you said, they don't really need it because of their traits. Yeah, it would be. Yeah, I mean, if we get both, I think that would be very cool. Yeah.

I mean, C++26 plus whatever next, you know, tier two range adapters that we get in. One range adapter that I'm sad that I didn't put as tier one is scan because I have a list of what I'm going to call like 10 problems. I currently, there's only five of them. And some of them are just beautifully like the before and after, you know, C plus plus 23. Now that we have, you know, adjacent transform and, uh, the range adapters there is they're just, uh, it's so beautiful. The talks, the talks that I have lined up, it's going to be amazing. But scan is one that's missing still that arguably should have been in the tier one category,

but it's all right. We'll get it in for, you know, there's a, there's a pretty straightforward solution to that problem. Connor. What's that? Well,

you could, you could write a paper that specs out what view scan would look like, and then we could talk about it. That's true. That's true. I mean, it's Bryce's fault that I have not really written or authored. How is this my fault? This is your fault because my very first committee meeting that I went to back in 2018 was in cologne uh it was like the july meeting and i came out of that meeting like super enthused and i was like i got to write all these papers and you told me no you said no connor you're not writing any papers you

have to go and figure out the like finished algorithm model like you're only halfway through your journey and like once you finish and i was like what oh yeah i just i just wanted to like i wanted to write i think uh the missing algorithm a couple missing algorithms from like the talk that i yeah well i didn't want you to do it piecemeal i stand by that and then so i i was like okay and then like that motivation to write papers has like never returned uh and also too like there's a certain amount of inertia because there's like three different ways to write papers and uh, you know, there's no, I mean, Michael Park has a blog on how to do it his way. But, you know, I see some people, they just submit their papers in like a Word document. But like, you know, there's like that initial inertia, like the same

thing as like setting up a Ruby Jekyll blog. You know, it's like the two hours that it takes to go and figure out and install Ruby 2.7 or 3.1 or whatever the heck it is on to like, it's super easy once you've done it once. But if you've done it zero times, AKA writing a paper, you know, it's like, you know, what do I don't really know? It's like, you know, obviously for Barry, you've written so many papers. It's like, it's like a nothing burger, right? And it's like, you know, you go and copy some directory and after the races, change the title, change the date. And you're good to go. I have a script now to construct a new directory structure for a new paper.

Also, you're clearly a better man than me if you can set up a blog in two hours, because that is very optimistic. I mean, I mean, now it takes like probably less than an hour. But the first time I did it, it might've been a weekend. It might've been, uh, it might've, yeah, I can't remember. Um, but it, it was like, it was, it was like pulling teeth. Cause you know, Ruby and Jekyll, it's like not really maintained. So half the things you do, you end up getting errors.

And, uh, then there's some magical command that you put pseudo in front of and a couple hyphen options. And then finally, it works. And then you're like, oh, that wasn't that hard. And every single time I migrate to a new workstation or laptop, and I'm setting the same thing up, like Ruby's upgraded and half the things don't work. And it's a whole 40 minute process. Anyways, we're past the time. Anything you want to mention? You have any talks lined up that people can look forward to in 2023 planned or submitted uh i don't have anything lined up i gave a talk at cpp con last year um but the it's not posted yet um and i'm going what yes it's not up yet they in 20 from like september 2022 uh yeah yeah what's what's going on they're dribbling them out they only post like five a week um

and there are a lot of talks at that conference so i'm really also going to give that talk again at the chicago meetup um next week two weeks from now two weeks from now rob douglas has finally corralled me into a date um so that's gonna happen again perfect if you're in chicago c++ will put a link in the show i assume they're on Meetup or something like that. I think so, yeah. January 31st. January 31st. And anything else you want to announce or plug?

No, I got nothing to plug, I guess. All right. We'll throw your Twitter handle. You're on Twitter. Are you on Mastodon? Have you gotten the lifeboat? I am not on Mastodon. I do not understand Mastodon.

Yeah, me neither. It's too complicated for me all right well thank you so much for coming on and uh answering all our questions thanks for listening we hope you enjoyed and have a great day