C++ Club - 159. C++23, WG21 February mailing, networking, safety, profiles, contracts

Episode Date: April 6, 2023

With Bjarne Stroustrup, Gianluca Delfino, and other colleagues.Video: https://youtu.be/dtR_HwGff8sNotes: https://cppclub.uk/meetings/2023/159/

Welcome everyone, this is C++ Club number 159 and today is the 2nd of March 2023. We have quite a few topics to go through, so I'll be quick. First of all, we have a bit of feedback about the last episode. Roy Barkan wrote on YouTube regarding the proposed shorthand concept syntax. He said, I believe C++23 has a new meaning for auto curly braces x, which is decay copy of x, and thus is problematic to use it for concepts in place. Right, that would explain it. Regarding proposed safety profiles, he commented, I wonder if there's a thought given to backward compatibility of profiles. Like if a piece of code compiles with profile X in the year 2023, can we allow the same code to be marked

non-compliant with ProfileX in 2025 or 2029? As time goes by, more profile checks can be implemented and I personally think they should be encouraged regardless of compatibility. I guess that's similar to what we have now with compilers improving from version to version and enabling new warnings, maybe. So old code sometimes becomes... I think we need some examples before we make policy decisions. Right. Apart from that, I didn't know that auto with X in brackets had been approved. It doesn't mean that it hasn't, but I hadn't noticed.

Right. Need to double check. So basically that syntax is taken now if it's correct. Is that what I am understanding? That's my impression, yeah. As a note, how awesome is it that we are getting comments on the video? I mean, thank you, Roy Barkin. Thank you, Roy Barkin. Regarding erroneous behavior, he writes, I think an example of errors of this nature are things referred to as if NDR ill-formed, no diagnostics required. For example, I'm not sure, but I think violations of the one definition rule can't always be caught across translation units by the linker and thus considered as such an error.

One difference from UB is that the compiler is required to compile UB code successfully and allowed to fail on if-NDR. I need to double check the paper about the the erroneous behavior but from what I've noticed it didn't get a consensus or some more work was required something like that. I think that's right I think the idea of distinguishing between different kinds of things that can't be checked. It's a good idea, but there was doubtful details in the role of behavior, just like there's doubtful details in UB. We need to work on that. Okay, so one of the main topics today is C++23 got finalized. And Daniela Engert writes on Mastodon, the sausage is made, the bread is baked, we now have C++23 with crossing all i's and dotting all t's, the best C++ ever for all of you. Much of it is already implemented and released in compilers

and can be used today. More will become available in the near future. By the way, that talk was very good, the one that's on the slide. Recommended. The one that she builds slowly throughout all the code, and she goes through all these asynchronous interfaces, and it's very thorough and somewhat mind-blowing by the end

to the point that, I mean, at the end I was thinking, can I even do this? It gets so far and so amazingly far that you think, this is way past what I thought it was possible. Yeah, I think it was the best talk at CBPCon22. Certainly one of the best. I didn't see all of them, but this one was really good. Daniela also posted on Reddit with lots of useful links to the same talk and to the talk by Timo Dummler, how C++23 changes how we write code.

I think the most important feature in C++23 is import is Td. Right, yes. port is td right yeah yeah yeah i heard from the cpp cast from a couple of months ago that cmake is getting more support for modules and hopefully i'll get it right eventually but can't wait to actually start using modules and especially for destiny destiny. Yeah, the problem is the build systems aren't up to it. And with the build systems, people don't work as much as modules as they should. And since they don't work as much as modules as they should, the build systems aren't improving as fast as they should.

It's a chicken and egg problem. It's a question to do, yes. I tried it a couple of years ago. Yeah, we knew that this would be difficult. There's a few billion lines of code and a few million developers stuck in the old ways. But this is going to be major, even if it takes a bit of time. Indeed, this is a long thread. I caught a bit of venting from the thread regarding networking. Someone asked about networking, and Niall Douglas replied, I presented a bare minimum viable vehicle for C++ 26 networking at the ISAQA meeting, made viable mainly by dropping anything to do with async.

It got killed. Committee wants async. Committee also wants several ponies and many unicorns in networking. Committee wants it all and currently doesn't seem to care if that makes timely delivery impossible. I especially remember in the comments to my paper around the room, there were clearly three separate factions, most with the opinion, either it's my networking, or I'm strongly against or over my dead body, because the networking of the other tribe is the worst

and would actively destroy my networking for various vague reasons. Which kind of networking is he proposing? Is he proposing the sender-receiver kind or ASIO kind? No, I think it was like, like he said, a bare minimum not based on the async proposal, kind of using the previous the existing networking TS I think yeah it's definitely two fractions the ones that wants the sender receiver and nothing else and then there's people who wants SEO and can think about something in the future. And then there was some people talking about security issues where they didn't want just mere networking. It had to be secure networking or nothing.

That is a big problem. Yes, but that's three fractions. And then you get combinations of those to make it very difficult. I would have accepted the SEO-based stuff and then worked on with the sender-receiver, and we might have gotten something basic followed by something better but that's not the way that group seems to to think they they want the right thing at the first cut they don't seem to have realized that perfection is is not obtainable if for no other reason

that the world has changed by the time you get to it. And, yeah, of course, you know, there is going to be different designs by then, but even just waiting to solve all the current problems in the current way would take a long time, even if things didn't change. We've used SEO successfully for 20 years or thereabouts. But do we have like the problem of the security? It's something that I don't even know how one possible possibly go about it because how do you if there is like a secure socket and there is a patch to be had? Is there ideas on how to provide those? Anything to do with security is very difficult. Not every connection is

going through an insecure channel so that you have to have all the encryption, all the setup in place. Not silent in fact. But yeah, so if we're waiting to solve all of those problems, including the security problem, that's something we're never gonna get basically. That's my concern. I think the time has come to standardize something,

but this is a group with great expertise and very strong opinions. And they seem to each time they get to something that's almost acceptable, they get a better idea. That is a problem. Yeah, so it looks to me like ASIO will be the C++ networking go-to solution for the foreseeable future. We'll see. We've been so close several times. Right, so Steve Downey has this repository where he collects all the features for a particular... approved features for a particular standard, and this is this, outputter, ranges to, formatting ranges, standard library modules, std and std all, and formatted output, and multidimensional subscript operator. And the rest of the approved features are in this

repository, so it's very convenient to skim it and see what's new. Does he mention flatMap and flatSet, which are minor additions but maybe worth a mention. Just one mention, but it's not in the context of it being approved. I don't think it got in. Other publications also noticed there's this InfoWorld with the article C++23 language

standard declared feature complete. So, yeah, congratulations and huge thanks for everyone involved. This is a massive effort, especially with the pandemic still going on. Yeah, at the meeting, several meetings, half of the people were not in the room, and we had to deal with the fact that they're all over the world this wasn't bad the thing that worries me most is that people just turn up to the one thing they're interested in and the committee as a whole thereby loses touch of the whole language and the connections between the different parts of the language, which are very hard to deal with. Feature interaction problems are never easy.

Right, there are some ISACA trip reports Inbal Levy posted on Reddit, thoroughly documented everything that was discussed. It's quite a long post. Have Sata posted on his... Is auto X there? I hadn't noticed. I'll need to double check that. You had me worried up there with the first comments. I'll see if I can verify that.

Herb Sutter posted on his blog C++23, pandemic edition is complete. There is a big photo of all the participants. Quote, the previous standard C++20 was completed in Prague in February 2020, a month before the pandemic lockdowns began. At the same meeting, we adopted and published our C++23 schedule without realizing that the world was about to turn upside down in just a few weeks. Indeed, now that I think back to it, it's surreal what we had to live through. And he continues, C++23's main theme was completing C++ 20.

So it's kind of a bug fix release. A bit more than that. I mean, there's a fair number of new features. And maybe we didn't quite work in the little corners that's needed. I think there's not quite as much type deduction. Maybe we didn't quite work in the little corners that was needed. I think there's not quite as much type deduction that I would have liked to see in a completing 20 world. But again, we were separated over the world, so it's hard to focus on little completeness things.

CppCast posted an episode about the ISAQUA meeting which is called ISAQUA Trip Report and how the C++ sausage is made with a guest Nina Ranz, and she explains very well how this all goes down in the committee, so I encourage you to listen to it. A paper. A paper, or rather a set of slides by Bjarne and Gabi. Safety profiles. Type and resource safe programming in ISO standard C++. There is a Reddit thread. The slides are very interesting. There's quite a lot of them actually, so I'm not going to scroll through all of them. The NSA memo is listed as a cause for concern, but not panic. I like the not panic in the brackets because I get the feeling that a lot of what's going on in general in the community, it's a bit of a knee-jerk reaction to this NSA announcement.

That's my feeling. Yeah, I get the same feeling. And they get focused on exactly one thing and then they are full of opinions and a lot of them started yesterday one of the things to note is this set of slide and the work that's based on them started at least seven years ago or you could say it started long before that, like when I worked on the JSF coding standard. It's more subtle and more detailed than people think. I've had some problems expressing it in such a way that people understand it. And I think using the word guidelines misled a lot of people,

and some people claimed that we didn't know what we were talking about because clearly static analysis can't do the job. Well, up front, every single time we say that static analysis by itself can't do the job. We need guidelines to simplify the language to the point where static analysis will work. And then we need libraries to simplify the coding so that the simplified language can actually do the job we want to do. There's three legs to this approach. But the naming of guidelines and naming of static analysis confused people a lot.

So I gave two versions of this talk in Issaquah. the first day to the study group for safety SG23. And it went very well. But I noticed that some people were not getting all of the points. And then the next morning I was talking to people, and I was using the word profiles a lot. And I realized it wasn't on the slides. And then I went and edited it. And now I could name what I was doing.

And that helped a lot in understanding. So in the broader audience in EWG, where I had to present it again the next day, things went down much better and actually much better than I had expected because it's a very controversial issue. And then I found again that obviously we weren't the only one who's got the idea of profiles. There's actually a proposed ISO standard for ADA for using some profile work. And there are some other things. There's more than one profile being used in ADA. And they actually picked the same word, independent. So, no, this did not come out of nowhere.

But as usual, I was poor at naming. Names are hard. There is a long Reddit thread with the discussion of this. Niall Douglas writes, quote, After Bjarne's presentation, there was much outside of room chatter about his proposal. I won't go into details, but suffice it to say that several leading committee members felt it had similar showstopper issues as Epochs had. If they succeed in persuading Yuji of the same, those proposals in their current formulation are dead in the water.

I think there's a confusion. I don't think, I don't see how this is similar to epochs, but maybe I'm missing something. One of the key things here is that code that passes a profile has exactly the same meaning as if the profile hadn't been applied. That is, it provides a set of facilities and a set of checks and constraints, but it doesn't change the semantics, not at all. We don't have the problems of people mixing an epoch with one implementation of a standard library and another one with a different one,

with templates having different instantiation meanings and different epochs and things like that. None of that happens. Obviously, not everybody likes a direction because it's not perfect. It's not complete yet. But we need a direction to solve the problems. It is not a simple problem. If people are looking for a simple problem to world security or even to type safety under performance and compatibility constraints. They're daydreaming.

Yeah, I don't think you can have the two. I think then you either have compatibility forever or you have maybe some breaks and you accept those like the Rust solution where we do those does they don't call them epochs they call them some other way but and yeah i mean it's a choice and it's perfectly fine to to go in that direction but unfortunately it's not an option for c++ and and i don't think this incurs in fact i don't think it incurs this proposal in any of such problems because the code still compiles exactly the same. There's no something that is going to confuse people in the sense that

different code generation is going to happen. We're just going to have different acceptance levels for different profiles. Right. The problem I was trying to address in the early days we're here is we need compatibility and we need to have better code. You can actually have both because you can't simplify the language without breaking compatibility, but we can improve use of the language by better libraries, by better guarantees enforced by static analysis. That's the approach. Don't mess with the language. Mess with usage as appropriate for a particular area. Your requirements for the code may not be the same as mine, and that's often fine. Is the idea that one can define a profile for just saying, okay, I want this kind of industry, this kind of profile, this goes, this doesn't?

Yes, there is the idea that we will get many profiles and some of them will be standardized. It has to be open because it's an open world and lots of people will want things like these. That's why I listed sort of 10 definitions of safety. But we can go beyond safety, like performance or real-time constraints. That's what's happening in some of the ADA profiles. I would like a teaching profile for people who are learning the language from the start. Training wheels.

Training wheels. What are your thoughts about Herb's new proposed front-end language that kind of tries to simplify and rewrite? Let's say I'm not a fan. But also notice that I'm not trying to yell people down just because they are doing things that I wouldn't do that way. I think about Herb Sutter's idea, it's great to have new ideas come in, and I hope that some of those ideas would eventually make their way back to the standard in a way or another. particular proposal itself. A lot of the people on Reddit wish they had const local variable, immutable variable by default and Herb Sutter, I don't think he agrees with that. So even in this particular proposal, there's already a little bit of contention. And so that's just another way

of having similar problems, not solving exactly all the problems and still introducing a totally new dialect. I mean, anything significant will be controversial. If you get something that everybody agrees to, I doubt it's significant. One thing that I'm concerned about, and I'll try and avoid with profiles, is the idea that you can't look at a piece of code and see what it means. That's what the problem we have with dialects. That's the problem you have with epochs.

That's the problem you have with languages that look very similar but have different meaning we try desperately to avoid that with c and c plus plus but you have people coming over from say java and thinking they know what the characters mean just because they are the same but but that's a different language, and that's fine. But I don't like to see such things within C++, and I'll try very hard to make sure that it doesn't happen. And personally, this is my opinion, I think this latest addition of making a safe loop, in every possible case, getting the

loop possible, dangling reference, Nikolai's fix. It's also kind of falling in the same category where if you are in the newest standard, then that's safe. If you're in the oldest standard, that's not safe. And adding yet another

special case, another special case another special rule so i don't know i i'm not totally into that myself evolution is hard gradual improvement is hard and with a large committee not everything gets just the way any particular person would like to see it. I guess that's fine, yeah. I mean, I learned a long, long time ago, like back in 1980, that I was not a dictator of the world. And I couldn't do just what I wanted. I had users. You have to listen to your users.

Sometimes they're right. Sometimes they're just flat wrong, but you still have to listen to them. And sometimes you are flat wrong. It's good to listen. Is it that Python's benevolent dictator, Guido Silvan Rossum, Did he recently quit as well? Yeah, he dropped out.

It worked for a long while though, I think. Everybody was happy until they weren't. There was some big deal with the walrus operator. There was a whole fight and he decided he didn't want to be involved with that and he's like, you guys go figure it out. But I think it's working now. He had enough of dictatoring. Right. So Janice presentation resulted in a vote. I think there were two strongly against, two votes strongly against. And this was one of them, a quote from Reddit. I was one of the people who opposed. To me, the question was ambiguous. Paraphrasing, is the approach presented in the paper worth exploring? It was not clear to me what do we mean by the approach, whether it's static

and dynamic checks on libraries. Yes, is it about how we delineate safe code and unsafe code? And is it about some of the concrete solutions like GSL-O they were strongly against that. So, hmm. The discussion in this thread was full of emotion. And who knew C++ developers can be so emotional. Speaking of, the next one. An article by Jimmy Hartzell. My reaction to Dr. Stroustrup's recent memory safety comments. Quote, to be honest, I was disappointed. As a current die-hard Rust-ation and former die-hard C++ programmer, I have thought and blogged quite a bit about the topic of Rust versus C++. Unfortunately, I feel that in spite of the exhortation in his title to think seriously about safety, Dr. Strohstrub was not in fact thinking seriously himself.

End quote. Oh boy. The article contained so much venting it could fill a surveillance air balloon. There are a few strawman arguments, including a jab at Bjarne for allegedly using a strawman argument. And a lot of pent-up emotion. An entire section is dedicated to defending the use of C slash C++. The tone of the article is quite condescending, that of the I know better variety, and honestly makes for an unpleasant reading. Maybe it's just me.

I think the problem is when you start with being a diehard fan of anything, I think maybe it's less subjective. It's a red flag, I agree. I mean, you're a fan of Rust and don't like C++, I get it. Just keep using Rust, nobody is taking it away from you. For us to become popular, C++ doesn't have to disappear. But no, it's a zero-sum game for the author, who cannot stop himself explaining to Bjarne and the rest of us the errors of our ways. The author's Twitter profile reads, Systems programmer in Rust, Haskellfan, had a bitter breakup with C++ and never looked back. never looked back." For someone who never looked back, he seems obsessed with his ex.

To sum it up, I read these sorts of articles so that you don't have to. Don't waste your time on this one. Much appreciated. I did see it. I don't have any comments. Yeah, skip it. I like critical articles, when they say, look, this should be added, this is good, this is bad, and there is some objectivity to that, and less emotions. That's what we're all for. Yeah, this article is not at that.

Rust safety is not superior to C++, Giannis Strohstrup says. This is the discussion on Slashdot and something I thought... By the way, have you noticed that the titles of all of these articles discussing the profile proposal comes up with, Bjarne says this, Bjarne says that, which mostly isn't in the article. It's their summary of something that I'm supposed to have said, and very often I didn't. I didn't see that. People are articles and the headlines tried to encourage emotional discussion, I think. It's creative interpretation, I guess.

Something like if you asked OpenGPPT what was the article about? I think that would be more objective, to be honest. Maybe if you ask as a preamble, make it into a Ragebait title. Then you would. Something I thought I'd never say, but this discussion on Slashdot was pretty sane, I thought. Yeah. The evil atheist writes, quote, you don't need to change the C++ model. You can write static analysis tools to do the same thing, which is exactly what he talks

about, even in the summary. You literally can write a borrow checker as a tool rather than make it part of a compiler. The core standards guideline support library is one of those things that, coupled with the newer language capabilities, is being used to do stuff like this." End quote. Yeah, I thought that was a good discussion and many other insightful comments in this thread. Some compiler security news.

There is a request for comment in Clang front-end discussion board about C++ buffer hardening by Louis Dion. And he says, we plan to implement a hardened mode of libc++ in which several cases of undefined behavior are caught and turned into assertion failures instead. So yeah, compiler developers are not standing still and that would be a good improvement, I suppose. By the way, there's some estimates that you get about a 3% runtime overhead,

which for most people would be acceptable. And for some people won't. And then the answer here is you can choose. Yeah, that's very good. I suppose you could just leave those checks enabled at runtime if the penalty was acceptable. Exactly. What is acceptable depends on what you're doing. Both the cost and the benefits. There's a proposal in the standard for something along

those lines to do with initialization. This is another interesting work by Apple. They use their own operating system kernel and apparently this is already live in iOS, but they want to make it more widespread, like in macOS, I suppose. This is a new way of allocating memory at the kernel level, where the kernel itself makes sure that a particular area of memory can only be occupied by an object of one single type during the lifetime of the program. So a whole set of vulnerabilities just disappear. Those who are based on time planning and interpretation of memory. So that's interesting as well.

How is it enforced and how can people opt out? That's the question. This is a long article, I only skimmed it. They have examples of the code that can be attacked in this way. Like here, for example, you allocate an array of structures of one type and then free them, but at the same time have another pointer to that same array and reinterpret the freed memory as another type or something like that. Yeah. The C++ core guidelines catches that kind of stuff at the latest time. I think they also wanted to be available to C as well as C++. I noticed they never use C slash C++ in this article, which is a win.

Yes. This is another one of those articles called about safety, security, and yes, C++ and Rust. And I like this article very much. It was... Safety is not security. Some people forget that, especially computer scientists. This is by David Teller, quote, I've seen many misunderstandings about what safety means in programming and how programming languages can implement help or hinder safety, end quote. This was a very sane and entertaining reaction to the NSA and Consumer Reports documents

regarding C slash C++ and the resulting Reddit threads. The old Bill Labs security course started with giving people a set of lockpicks. And for the second meeting, you had to get into the building without using your access card. I teach people that there's different kinds of safety, different kinds of break-in techniques, and that for security, you actually have to look at them all. This was the same kind of people that asked questions like, when you park your car in the airport,

what is the best way of it not getting stolen? Answer, park next to a more expensive car. Any self-respecting crook will attack the weakest point. It's logical. By hardening the weaker points. It's all gradual. Quote from the article, your favorite language is not perfectly safe.

It is not perfectly secure. It is not even safer and more secure than most other languages for all teams of developers, all domains, all threat models. If you are reading these lines and must remember only one thing, please, fellow developers, in your favorite language, stop trolling developers with different experience. Chances are they are perfectly right to use these tools that you despise. Even if they are not, trolling is not constructive. And he ends with this, quote, use whichever language makes sense for your goal, specs, and threat model. There are many use cases in which I will be using Rust

if I have a choice, but I'll happily use a different tool if it feels appropriate." End quote. So yeah, very well put. Somebody's trying hard to be seen. And now briefly let's go through some of the papers from the February mailing. It's quite a long one, so I chose just a few. This is another long rant in response to the direction group opinion on C++ safety. I won't go into it, but it's not positive. So let's put it like that. There's a saying that if people complain so much, I must be doing something right. I didn't invent that phrase. Yeah. Paper.

Introduction of StatHive to the standard library. Currently at revision 21. C++ 26? Maybe. A big decimal type. This paper proposes an exact decimal type that can be used as either a fixed point type or a floating point type with an implementation defined maximum precision. It's like decimal type in other languages like C-sharp. I think if it were accepted and didn't result in a big penalty in runtime performance,

that could be a win for anyone who counts money using doubles. Yeah. I used one of those when I was an undergrad. I had to build it myself too. And yes, I was dealing with money in a small memory. Yeah, counting money with doubles is pain. It's da it. As I said, if you need it... No, not if you can help it. This paper by Thomas Newman is called Towards Memory Safety in C++. This is version 0 and it proposes lifetime

annotations for function parameters combined with a general opt-in safety annotation. It struck me as very verbose, and if you look at the examples, you end up with functions with parameters annotated with lots of attributes, and it's just so much visual noise that the code disappears. My opinion is that if you have to use a lot of annotations, they become a problem. First of all, things get verbose, as you say. Secondly, people get them wrong.

You can't just manage with low-level annotations. People have tried that again and again. The next one is regarding contracts. It's called Not Halting the Program After Detected Contract Violations by Andrzej Kremensky. And it quotes a paper by yourself, Piana, unconditional termination is a serious problem. And this paper, quote, explores the possibility of not stopping the program after contract violation has been detected at runtime. This is a feature to be added to the contract support framework." The proposed solutions in this paper are exceptions, but the main argument in the paper

against that is, but what if we have a throwing condition check in a destructor? Well, don't do that. We did manage to avoid throwing from destructors so far. I mean, if you throw from a destructor, you are in trouble. And, well, if you wanted to in the safety profile, you make sure that it doesn't happen. And if you're in a normal situation, just something you don't do. And if you do it, you're in deep trouble sooner or later. There are just things you shouldn't do. And this one, interestingly, is one that you can actually catch if somebody tries. I mean, statically. As another potential solution, the paper proposes aborting the component, which kind of introduces a new notion of a component at the standard level. Quote, as a potential solution to the above problem, we propose a mechanism that is harsher

than stack unwinding, but softer than abort. In fact, we are proposing a stricter and simpler version of the set jump long jump mechanism. They propose a way to divide the program into so-called components and define sort of exit points for each component, which can be aborted separately from the rest. What does that do to the entire program? I mean that doesn't sound sane. It's not simple. It's actually very real in our code. Let's say we're relying a lot on RAII and to do some very meaningful work in the destructor,

sometimes closing the files or even removing the files. And these operations that are running in the destructor are prone to maybe IO exceptions and a few other things that we need to check. And our ability to somehow be able to, because most of that code that we call there, let's say removing the file, also can throw the exception. So right now what we do is blindly suppressing the exceptions, and that basically becomes known to anyone except maybe the log.

So some way to communicate the error condition from a destructor, especially if it's a core part of RAII idiom. Somehow that would be useful. The way I usually recommend it is to put an action on a list of actions to be cleared up. And so have the system look at that list ever so often and do the final clear up, asynchronously to getting out. Sockets that won't close is my standard example. Right. The next paper is a very interesting one.

Do expressions. This proposes a new syntactic construct in C++ called do expression, which introduces a scope but doesn't introduce a new function scope. So it's almost like a lambda, but sort of more in context of the function. This is the simplest form. int x equals do curly open, do return 42, curly close. A do expression consists of a sequence of statements, but is still itself an expression and thus has a value and a type.

This solves the problem of specifying expressions in pattern matching. And Michael Park, who is working on pattern matching, is one of the co-authors of this paper. This was very interesting. Apparently, it was constructed in the bar on the night before the votes, and there was a presentation. It was a nice presentation, and for something that was done in four hours, it's great.

I think there was a problem where it gets in and try and solve everything. It's yet another version of how to make C++ more like an expression language, as I've dreamed of from day one, and I couldn't get it. So we'll see what happens. This proposal, I suspect, will evolve. And that's very good to hear. I thought it was very interesting. It got into the weeds towards the end. I haven't seen this particular write-up, so they may have improved it since I heard about it. That was two weeks ago.

I think it's still revision zero, this one. Certainly a proposal to watch. I like the way it will allow us to be very easy for having loops and initializers. Finally, a book that Christopher DiBella is writing at the moment. It's a book that he continues to write chapters for, and you can watch and just read whatever he wrote. I think it's going to be a great book. And another book is available already in the PDF format by Shimon Toth, and it's called A Complete Guide to Standard C++ Algorithms. It's a free book on GitHub, and it's written in LaTeX of all languages. So it's very nicely typeset. Right. I think I will end on that today,

although I have still a ton of material left. So yeah, next time maybe. And I'll leave you with this toot on Mastodon. Shantini, who is an Apple engineer, says, quote, people will always see your software as the bugs you write, so make sure you write really epic and memorable bugs. And the last one is a piece of poetry that anyone,

especially who uses Git, will understand. By Robin Seale. Roses are red, my code is a disaster. Git push force origin master. Oops. That's it for today. Thank you very much for coming, and I'll talk to you soon. Bye. Bye.