CppCast - Contracts

Episode Date: June 23, 2023

Joshua Berne joins Phil and Timur. Joshua talks to us about the previous week's ISO C++ meeting in Varna, Bulgaria, then focuses on the current state of the contracts proposal that he has been central to, as well as a bit of its history. News ISO C++ trip report's from Varna: Herb Sutter's trip report Jonathan Müller's trip report GCC 14 NRVO enhancements (Reddit) P2025 proposes guaranteed NRVO How to get NRVO before C++26 XCode 15 beta Links P2831 - "Functions having a narrow contract should not be noexcept" P2521 - The current contracts MVP P2695 - "A proposed plan for Contracts in C++" P2811 - "Contract-Violation Handlers" P2834 - "Semantic Stability Across Contract-Checking Build Modes" P2877R0 - "Contract Build Modes, Semantics, and Implementation Strategies" P2751 - "Evaluation of Checked Contract-Checking Annotations" P2552 - "On the ignorability of standard attributes" p2786 - "Trivial relocatability options" P2839 - "Nontrivial Relocation via a New owning reference Type" P0843R8 - "inplace_vector"

Episode 363 of CppCast with guest Joshua Byrne, recorded 21st of June 2023. This episode is sponsored by JetBrains, smart IDEs to help with C++, and Sonar the committee meeting in Varna. And about compiler news. Then we are joined by Joshua Byrne. Joshua talks to us about C++ contracts. Welcome to episode 363 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today? I'm all right, Timo. How are you doing?

Well, I'm melting. It's very, very hot here in Finland. It's almost 30 degrees, which never happens here normally, but otherwise I'm good. I had a very productive week last week. I was in Varna at the committee meeting. I got pretty much all my papers made progress. So I'm very happy. We'll hear a bit about some of that, I'm sure. It's been quite hot here as well, similar temperatures, but it's also heating up in advance of C++ on C next week, getting to that really chaotic stage where actually everything's going pretty smoothly,

relatively speaking, but it's still chaos in absolute terms. So it's going to be a fun week. Yeah. Conference organizing is tough, but also great in its own way. So I'm very much looking forward to being at your conference, Phil, next week. I'm looking forward to you being there as well. Otherwise, I'm going to talk short. All right. So at the top of every episode, I like to read a piece of feedback. And this time, we received an email from Ingmar. Ingmar writes, I'd like to thank you for doing the podcast. It was greatly missed when Rob and Jason stopped doing it. And it's nice to have it back alive. Although often the topics seem a bit esoteric, quote unquote, or very low level for someone just developing things with c++ instead

of developing c++ itself it is always containing something to further understanding and learn new things never missing an episode though so don't take it as too much criticism what do you think are we are we being a bit too esoteric or i think we can at times uh when we obviously try to cover a mix of topics both from like from heavyweight, real sort of nuts and bolts of this is the future of C++, those sort of forward-looking discussions, which we're going to have a bit of today, I think, but also some of the more bread-and-butter topics,

the everyday stuff. So perhaps we are more biased towards the former just because that's where our focus is, so maybe we don't notice if we take a bit too much of it. And also because people that come on,'s often that what they want to talk about so maybe we just need to try a little bit more to to get more of the uh the other type the bread and butter stuff yeah i believe we have a few guests in the pipeline that will be talking to us about libraries that you can use today and kind of more hands-on stuff so i'm looking forward to

those those episodes and you can look forward to those too. Well, we'd like to hear your thoughts about the show. You can always reach out to us on Twitter or Mastodon or email us at feedback at cppcast.com. Joining us today is Joshua Byrne. Joshua has been programming in C since he read Kajanar over the weekend to participate in a computer science competition

in high school without having to do it in Pascal. He's been programming in C++ since he read Bjarne Stroustrup the C++ programming language the following week because of how hard that competition ended up being. Though most of his career has been spent writing high-performance distributed financial systems and Java, C++ has remained his favorite language ever since. Joshua now works at Bloomberg on their core C++ libraries, most notably their internal contract checking framework, whereas he's lucky enough to be able to focus most of his actual time on research, writing, and improving the C++ language for future generations, especially his son. Josh, welcome to the show. Thanks. It's great to be here. Thanks for inviting me.

So Josh, if I heard that bio right, you did C for about one week before ditching it for C++. Is that right? Yes. My first C program where I actually had a compiler available to me, because this was back in the days when I didn't have, I couldn't just download one off the internet and start, you know, coding along with reading the book was for the International Computer Science Olympiad competition. It was six hours of trying to program stuff in a language I had only just learned, and it didn't go great, and it lacked abstractions. And then I was lucky enough to have a computer science teacher with a wide shelf of books who would happily hand me the next thing he thought I should read. And that turned out to be C++ right after that. And I liked that a lot more. Did you ever get to use C professionally?

Not seriously. I've used C. I mean, there's a blurry line between using C and using C++ in a lot of places. I've definitely used effectively just C in a number of places, but never for anything large. Yeah, C with classes. Again, I did a lot of my work in the Java space, and you're always writing C to start whenever you do anything with JNI. So you need to know that end of the language and that side of the world

all right josh so we'll get more into your bio and your work in just a few minutes but we have a couple of news articles to talk about so feel free to comment on any of these okay sure the first news item we have today is obviously about last week uh the iso c++ committee meeting in vana bulgaria took place last week and it was a very productive meeting um josh and i were both there along with another 100 or so people in person and another 70 or so people joining us online and so i guess we're going to talk about some of the things that happened there later with our guests in this episode if you do want to hear the full story um there's at least two reports that are out as of right now that you can read. One by

Herb Sutter, which he posted on his blog, which is a very good summary of the things that happened in Varna. There's another shorter and a bit more personal trip report by Jonathan Müller, who works at ThinkCell. And there will, I think, also be a very detailed

trip report, which is the one that's usually put together by various people and then posted on Reddit. But at the time of recording this episode, it has not been posted yet. But I think it hopefully will be. And if it will be between now and Friday, then we will include it in the show notes.

I can put it there when it does arrive anyway. All right, then we have some compiler news. So GCC14, there was a post on Reddit that was talking about the NRVO enhancements in GCC14. NRVO, of course, stands for Named Return Value Optimization, which is where you have an object which is a named value

and you return it from a function and that doesn't generate any copies or moves or anything like that, but just directly writes that object into the space kind of memory on the caller side. And so apparently GCC recently gained many improvements to NRVO authored by Jason Merrill, another fellow committee member.

And one of them is a new warning, minus W NRVO, which actually warns about missed optimization opportunities. So it's a bit similar to a minus W pessimizing move. Jason also fixed several bugs surrounding NRVO and also implemented part of the guaranteed copy elision for return variables paper, P2025. And you might remember that Clang recently got a similar optimization as well. So yeah, I think that's really cool. So P2025 is a proposal

that kind of proposes guaranteed named RVO, which is kind of better than what we already have since C++17, which is guaranteed non-named RVO. So if you return like an unnamed temporary object, then it doesn't have to be copyable or movable or anything since C++17. So P2025 proposes to do the same for named objects.

It's not in the standard yet. And I don't actually know the status of that paper. But apparently, compilers are already implementing that. So I think that's really cool. I think it's a great paper. I think it would be nice to see it land. I'm always a little worried about how it interacts with allocators because the whole NRVO return type when you have a local allocator is a bit

of a foot gun. And one of the reasons we're sort of separately trying a long-term push to get allocator support more integrated in the language so cases like this can clearly identify like you're using a local allocator in this function so i'm going to make this not eligible for nrvo and align the copy and give you an object with a dangling allocator also is the dangling allocator the problem or is the problem that the allocator is not going to be copied yeah because the subtle thing about the subtle thing about nrvo is it flips your understanding of object lifetime you suddenly have this object you create in a local scope inside your function that's now going to

live somewhere else long after your function returns and that that that breaks some assumptions people will try to will tend to make make about what can this object refer to. And allocators in particular, like if you create a local memory resource and try to use it for an object that's going to be NRVOed, that local memory resource, even though it's visibly scoped outside of the object you're returning, now doesn't live as long as that object.

But I think we can already get NRVO in a lot of cases, like in C++ 17, 2023. Yeah, this is a foot gun you already have. So you can do this trick that actually Raymond Chen discussed in one of his blog posts that we can also link in the show notes. I like that one. Where basically you can declare a move constructor of his blog posts that we can also link in the show notes i i like that one uh where um basically

you can declare a move constructor so that it compiles but then you don't define it and then you rely on the compiler not actually using it because it does like an rvo so before c++ 17 you had to do this trick with rvo as well but now you still have to do it with nrvo and so that's where you already fall into this trap that you're describing, right? Yep. Anywhere that NRVO or this allowing NRVO to apply in more places just expands the scope of the trap.

The trap is there already. All right. Do you have like any paper in flight to fix it or any ideas? Yes. So the getting allocators support sort of built into objects, the whole scoped property model that Alistair Meredith is working on, which sadly did not make progress last week in Varna because of illness. But we're hoping to keep moving that forward long, long term.

This is not coming soon, but coming eventually, we hope. So that's a Raymond Chen post. I had a quick look at it and I wasn't sure if it was enabling NRVO by adding the move constructor or just making sure that if you didn't get NRVO, it wouldn't compile. Because if you declare a move constructor, whether you implement it or not, that will delete the copy constructor and copy assignment operators. So if you don't get any RVO, then it won't compile because you won't be able to copy it, or move

it, in this case. So I was guessing that was what it was about, or do you know more? Oh, you might be right there, Phil. The trick means you don't link if NRVO didn't happen. So it's a way to force, I mean,'t happen right so it's it's a way to for i mean it pre c++ 17 it was a way to force getting rvo or nrvo when you want it to happen in in 17 and above it you

can i mean it only is really meaningful for nrvo but it means like if you're going to use the type and you want to nrvo it you you can still try to and you get a link time error when you when the compiler didn't choose to do it yeah because that's the problem it's not guaranteed even if it's guaranteed it's not guaranteed to be guaranteed then it's nice for the compiler to tell you when it doesn't do it right so i have one last news item for and today which also has to do with compilers xcode 15 the beta for xcode 15 came out two weeks ago actually it came out just before we recorded the last episode but it came out after we put together the show notes so i didn't make it into the news items for last time so the xcode 15 beta is out and apple now has a page,

which I'm not sure if it was there before. I never noticed it before, at least. They have a page called C++ Language Support, where they list basically what C++ features Xcode and Apple Clang supports with links to all the relevant papers. And I believe it has the same information as like the apple clang column on the cpp reference page that lists all the compiler support for um kind of all the new features but this one is on the apple website so it seems like more official um so that could

be useful on the other hand the cpp reference table also has all the stuff that apple clang doesn't yet support which the apple website obviously doesn't list. It's not entirely true, because if Apple Clang supports a feature in general, but does not some specific aspects to it, like concepts, it supports about half of it, then it does list which proposals make up that feature that it doesn't support yet. But if it doesn't support the whole feature, yeah, you're right, it doesn't. It doesn't say. right so um apple clang is a bit behind uh the normal clang which everybody knows who's trying to use kind of the latest c++ features on mac os but they are catching up um i guess they just kind of fork forks clang and then they're kind of i don't know how far they're behind but the version that they have now in xcode 15 uh supports a bunch of new features

so from css 23 they can now do uh delimited escape sequences uh named universal character escapes they support const x per unique pointer they support static operator prem paren and something that i'm very excited about personally they support std expected in the standard library in xcode so that's really really cool so you can now use std expected on macOS and iOS. And I think that's really, really cool. And they also support a few more kind of C++ 17 and C++ 20 features that they were behind on. Most notably const val,

that's a C++ 20 feature, which is really cool. Source location, char 8 underscore T, the kind of UTF-8 native character type, and polymorphic allocator, which is something that I heard from several people that they were waiting for that for a while. Although I'm not sure if it's just the polymorphic allocator or also the kind of memory resources that are in the PMR,

like monotonic buffer resource and all of that stuff. So I didn't check if that's now supported too or not. That's not obvious from the Apple page, but I guess that's easy to test. That's something that some people use and find very useful. I think that PR for polymorphic allocator and just memory resource itself was sitting on Libs C++'s table for a very long time.

And we basically at some point asked Marshall Clow, why hasn't this been merged yet? And he went, I don't know. And basically merged it and we finally got them in Clang. Because the basic interfaces are not that sort of overly complicated to add in, but I don't know the status of the actual memory resource implementations. Yeah, me neither, but maybe somebody can let us know. It's always good to see Apple Clang catching up more, though,

because if you're doing cross-platform development, it can often be the thing that blocks you from moving forward if you're relying on the runtime to being on a machine. Yeah, like if you're developing an audio plugin, you always need to compile for Mac and Windows. And so you're just tied to whatever the subset of the languages that all compilers support, basically. And for a while, things like optional or variant, they were supported by Clang, but not by Apple Clang. So yeah, that was very annoying. So always very good to see them catch up. All right.

So that concludes the news items for today. And so we can move on to the main part of the talk, which is discussing what happened in Varna last week and also talking about contracts with our guest Joshua Byrne. Josh, hello again. Hello again. Actually, I'll ask the first question because it's going to be to both of you because you were both there in uh in varna last week so what actually happened what

were your main takeaways um so i think we made some great progress in sg21 sort of to some extent getting very solid consensus for the design that isn't that dissimilar to what we used to have but i think fleshing out a lot of details and doing it out in the open and getting everyone on board with it so we've had a remarkable string of great consensus in sg21 i think there were also some other lots of other interesting topics and threads in the other groups that I think are good to see making progress. There was a lot of talk about the LACOS rule and how that will impact library design and what our policy should be. And then there was a lot of talk about relocation, both trivial and not. And I think there will be some interesting evolution happening as papers related to that start making their way out of

the incubator groups and on into the evolution groups and hopefully into the language. So you mentioned the Lacoste rule there. I think we're going to talk about that a bit more later, but do you want to just sketch out what the Lacoste rule is for people that aren't familiar? Yes. So this is the secret committee jargon that I think a lot of people want to try to make open and more clear. But the Likert's rule is basically don't put no except on functions that have preconditions. And partly that's because no except is sort of a wide promise that can be checked and depended on that this function will not throw no matter what input you give it. Whereas when you have preconditions, when you violate those preconditions, you, you really want the flexibility to do whatever.

And that should be able to include throwing an exception. And you have that choice taken away from you. And there's conflicts, conflicts of interest when you have both, both, both on the same function. And so long ago when no accept was first added into the language and no one knew what to put no accept on or not in the standard library, this rule was sort of proposed and accepted and most of the standard library pretty much follows it and we're sort of trying to decide if that's the way we want to go forward or not.

And there were a lot of great discussions on that. Yeah, yeah. I actually gave a presentation on that at VANA last week. And John Lakers himself gave another presentation, and we had a very good discussion. So basically, yeah, functions with preconditions and stuff like vector operate a square bracket, right? It just returns a reference to an element. And you know that's never going to throw an exception but you still don't put no except on the function because if you do that

then you can't do things like throw an exception if the precondition is violated if you have like a check in there things like that so you disable you know very useful kind of error handling strategies and there's other conceptual reasons why why the rule sense, which are not related to testing as well. But yeah, we had some good discussion on it. I think, you know, there were some people who were saying, hmm, maybe, you know, we don't need that rule anymore.

But I think now kind of we're coming back to the, slowly coming back to the conclusion that we kind of still need it. And we especially need it, you know, when we get contracts, because that kind of ties in with contracts. That kind of really nicely,

if you follow that. You do. Yeah. So my other takeaways would be obviously i gave me great progress with the papers that i was working on so that's always nice yeah um i got my uh attributes ignorability paper through that's p2552 i got uh in place vector which is the new name for static vector because static vector is a terrible name, because static means something entirely different. So that's the thing where in-place vector is where you have basically the storage of the vector inside the vector. There's no heap allocations. Static can mean so many different things. It might as well mean one more.

So it's a vector with fixed capacity and everything's on the stack. And that's P0843. And we got that paper design approved by lewg so it's going to wording now so that's really cool and yeah then the other the other thing is obviously contracts so we made great progress there actually people have been asking me even before vana lately about what state contracts are in and what's happening there and just just for context for the people who are listening who don't know kind of the jargon,

SG21, which is what Joshua was referring to earlier, is actually the contracts study group. And I'm chairing it. And Joshua is the author of both of those papers that we approved last week, or the main author of those papers. So yeah, there's a lot of exciting uh work that happened there last week so i thought it would be really cool to get josh on the show so we can talk about

it here so uh josh do you want to just for our listeners just quickly summarize like what are actually contracts and and what what are they for because not every listener might might know sure so when we say contract we really mean i mean it really is just an agreement between two entities right but when we're talking about contracts in the language what we really are talking about is contract checks you want to write a piece of code that says this is going to tell me if my contract the agreement between the caller of this function and the callee, has been violated? Like, did something go wrong?

So you write pieces of code that sort of say, help identify defects in your program and aren't really part of what your program wants to do. They are part of your program being able to potentially check and declare whether it is doing the thing it's supposed to do correctly um so most often it's easiest to think of these in terms of a precondition check like that's that's sort of the first thing you think of like if i want my function to only be used with certain inputs i can easily say like write a write an expression that says is this input valid or not

like square root Square root only works if you pass it a positive number or a non-negative number. So you really want to say like it has a precondition, the number is greater than or equal to zero. And you can write that as an expression. And then you can write a contract check that takes that expression and lets the compiler and other tools do something with that. The direction I come to this from is mostly because we have a runtime contract checking system that lets you turn on and off these checks in different builds. And then if your system detects a bug, it will fail or log something or let you know there's a problem that you have to go and fix. A lot of people are

probably aware of something similar. C-Assert does this already. It's sort of your simplest, most primitive contract checking facility that everyone has familiarity with. And then a lot of people come to wanting contracts in the language also because they want to say, well, we want to express this stuff and have it in the language so that static analyzers can look at it and then tell me, without me having to run my program is my program capable of violating one of these contracts

and then i can go put in the right checks and put in the right control flow so that it can't and then get you know safer code and better and more correct code and more correct programs so you mentioned cs-assert there. Why is the basic assert not enough then? What else does the full contracts facility give us or what should it give us? So there are a few big gaps between C-assert and not C-assert

and sort of the other contract facilities we're trying to get. The reason we have our own assertion facility at Bloomberg and that we're trying to get something similar in the language is customizable violation handling. So C-assert, you either it's off and does nothing or it's on and you get an abort and hopefully some kind of log message printed to std error that tells you what went wrong. But that's not great and doesn't scale when you sort of say, well, I really want something written to my log file, or I really want something sent to syslog,

or I really want something that, you know, when there's a problem just diagnosis that there was a problem, but then keeps going so that my program doesn't crash because of reasons. And so you have a wide variety of choices that you want to have available to you when a violation happens, and C-assert gives you no control over any of that. I think the other big gap is C-assert's always embedded within a function. It's a statement. I mean, it's a macro that expands to a statement and executes inside the body of your function. So there's no way to put that information on the declaration of your function and sort of see it on the interface. And to really achieve the dream of static analyzers sort of scalably being able to analyze, like, am I meeting all my contracts?

You want in a single translation unit to be able to say, to come to that conclusion. So you want to be able to have a static analyzer go, am I calling this function right without having to look at the implementation of the function? Because that lets you really point the static analyzer at one translation unit at a time and say, is this one correct? Is this one correct? Is this one correct? Instead of saying, point it at my whole program, which may be, you know, orders of magnitude bigger and say, is everything correct? And then by seeing the declarations of what the preconditions and postconditions of a function are on the declaration, static analyzers have that, then suddenly have that information available to them and can take advantage of that. And I think those are the sort of two big gaps that need language support to do it. Like having all contract checks go through a central violation handling mechanism that you can configure for your whole program and all the libraries in it is sort of one side of wanting sort of runtime checking unified behind something more powerful than just C assert. And then having,

having it on declarations instead of just inside function bodies, let let's let static analysis scale in a way that it just can't when it has to open up implementations and see them to understand like, how do I call this function correctly? Yeah. My colleagues and I at Sonar are definitely interested in the static analysis side of this and interested to see whether contracts

actually makes it into C++ eventually. Because, of course, it famously did make it into C++20 and then was taken out. And all three of us were in the room when that happened. Yes. Yes, I'll never forget that. Yeah. I mean, one thing we have when we're when we're doing uh this podcast we'll often interview people and we know the answers to the questions before we ask them because we know a bit about

the subject i mean it's going to be particularly the case today so yeah we were all in the room when contracts were taken out but let's ask the question why were they taken out? And what's going to make it different this time? So I think contracts got into the standard when multiple different groups were coming with contract proposals. You had one group that wanted to get sort of static analysis supporting tools onto declarations, and another group wanting to get sort of a better C-assert into the language that let you have central violation handling and made it part of the language. And EWG got tired of hearing both of them and said, you guys go away, come back with a unified proposal that meets all of your needs, and we'll talk about that.

And that happened, and it came back. And I think that happened in a closed room. The details of the discussions weren't really recorded and made public. There was a fair bit of haggling back and forth that happened over, I want this feature, you want this feature, we'll agree on something in the middle. And I think at the end of the day, everyone was convinced that the proposal they had was what they wanted. And then the wording that they actually got was yet a third design that was unrelated to that. And I sort of came into the picture at that point point like post that proposal being in the standard and i started

looking at it and going like the wording doesn't actually say what you mean to the people i worked with at bloomberg we like you you described this to me and then i looked at the wording and that doesn't match and that doesn't match what the other guys seem to think they they got out of this and so we tried to sort of get a clear well-defined wording and specification through and this this was beginning to happen sort of the last two meetings of the c++20 cycle and i brought proposals that sort of tried to do that that tried to keep the functionality of what was there but make it clear like we want this exactly to happen, not have sort of random undefined behavior introduced in places that people weren't expecting it, but have it available for people who wanted it in certain places.

That got interest from people, that got approval in EWG at the start of the meeting in Cologne. And then a lot of people outside of EWG sort of looked at that and went, wait, this is the end of the cycle. We're not supposed to be making design changes at this point. This seems like a big change. And then I think a lot of the people who came in to vote to just remove it were mostly doing it on the fact that there was an impression that it was too big of a change too late in the cycle to the future to sort of allow, like to accept, like it needed to be pulled back so that everyone really did have consensus on the design. Other people had different reasons for voting to remove it. Other people have claimed that's the only reason to remove it. But like, there's a lot of politics and speculation as to what else was why it got

removed. But the primary reason that I could see was people outside of EWG just seemed to have a strong feeling that it was changing too much right near the end. And I mean, I take responsibility for that because it was my changes that EWG was agreeing to. I don't feel they were changes. I feel like they were clarifications of the specification. But that's a separate – that is history we don't need to fight over any longer. It's important to know what happened before. Otherwise, those that don't know their history are doomed to repeat it.

So what's different now then? So contracts got removed that night. A bunch of us got together, had dinner, tried to sort of hug and make amends and be like, let's be friends now and try and figure out how to move forward. And that's when we sort of came to an agreement, like we need a study group, we need to figure out what contracts should be and have sort of a paper trail and discussion trail in public for why it should do the things it does and what the actual requirements are and all the things it should need. And that's when SG21 was formed. And that's sort of, we've been now following a process since then

to try and get SG21 to get a contracts proposal back into the standard that can eventually grow to meet all the needs that we know it needs to meet. And is not, I mean, at this point is not wholly dissimilar from what we had in C++20 contracts, but now has sort of probably a few hundred pages of papers backing up the minutia of all the decisions we've made and a lot of discussion and consensus for like, yes, we do want, we understand why this part is going to work this way and we want it to work this way. We understand why this part is going to work this way and we do want it to work this way and we want it to work this way. We understand why this part is going to work this way and we do want it to work this way. And that was previously in people's heads and not quite

matching with what the wording was saying and what people were going to be getting. So I think this time, once we get through SG-21 and get into the standard, there will be no legitimate reason to look at it and go, oh, this is changing too much and we didn't agree to this because there's a very long, robust paper trail and trail of consensus saying, yes, we've talked about this, we've answered every question that's been asked, we've come to agreement on doing this this way, here it is.

Yeah, so it's a very interesting exercise to actually schedule all these papers, draft all these polls, and actually make these people agree on stuff. And in the past, it was actually more challenging than it is now. I think now I feel really positive about it. The pieces are falling into place. I think more and more people are kind of seeing the big picture

and we don't really have much disagreement anymore. Which is really cool because that's definitely not where we were you know a few years ago just just looking at the last thing we got consensus on which was the details of the contract violation handler it is not a complicated thing it's just call this function populate a struct with sort of what happened when to describe the violation and that can do what it wants and my first version of the paper which basically described that was about 11 or 12 pages and then we had a lot of discussion and a lot of questions and a lot about well but what about this but what about this but what about

this what was the history of this what's history of this i think the final version of the paper we just got consensus on was about 65 pages or something like that. There were things that evolved as we discussed it, but largely unchanged, but filled with a lot more like, here's all the things we've considered. Here's all the things we didn't do, all the things we did do, how we think it might be implemented. All that stuff is now sort of written and there for posterity. And hopefully we'll get this to move forward more cleanly than the last time. Yeah, so we call this the Contract MVP. This is kind of going to be the first version of contracts, which we can get agreement on, which kind of gives you a very robust base. And then, you know, later, later we can add more fancy stuff to it and make it

more useful to more people. But yeah, Josh, actually, I'm curious about your opinion. What do you think? Is the contracts MVP, is it going to land in SuperSUS26? So I will make a relation to the fact that i started renovating my home in 2016 and every single time since then that i'd be told that i've been asked the question so when is your basement going to be done i've given a date i've been completely wrong so sometime i just stopped giving dates fair enough i i think i i have confidence that your plan is still viable but i refuse to say one way or the other that we will make the next train or not yeah so i wrote this like plan this is, what is it, 2695, I think. It's like a roadmap paper.

Yes. Yeah. So we're still on track. We're still following the roadmap. I think we just successfully made the next major design goal in that plan, which was we have a pretty solid definition of what happens, how contracts are checked, how they're evaluated, what happens when the contract is violated. All of that is now very solidly set. We have consensus.

If someone wants to change any of that, they've got to have really good reason to violate that plan. And we just have syntax as the last open question. So if we can manage to come to consensus on that between now and Kona in November, I think we're still on track to make that plan happen for C++26. So if I remember rightly, that plan was designed specifically to answer the question of what do we need to do and when in order to get contracts

into C++26. So if you're following the plan then it's still still on track my understanding yeah that's pretty accurate that was the idea of that paper yep it's just like what's the kind of feature cut off like the physical like last meeting where we can approve new stuff as user 26 and then kind of work backwards from there and it seems to me you're mostly just in this state of deciding what color the black shirt should be which is um something that the committee is excellent at doing so i think you're you're on the right track there so well i think we're going to dive into contracts a little bit more deeply what the current state is after the break but it's a good time to take a little sponsor break because this episode is supported by JetBrains and as

ever JetBrains has a range of C++ IDEs to help you avoid the typical pitfalls and headaches that are often associated with coding in C++. Exclusively for CPPcast JetBra brains is offering a 25 discount for purchasing or renewing a yearly individual license on the c++ tool of your choice that's one of sea lion resharper and resharper c++ or rider just use the coupon code jet brains for cpp cast or one word during checkout at jet brains.com all right uh we just talked talked about how we kind of mostly have agreement on a lot of things, but we still need to figure out what color the bike shed is. So we actually do have one major thing

that we don't have a solution to yet, which is the syntax. We did get agreement on a bunch of stuff like contract semantics. I remember that the original proposal for C++20 had these built modes. Now I got rid of those. So now we just have contract semantics. Josh, do you want to just briefly talk about what that is

and how that's supposed to work? So this was actually, this goes all the way back to that first paper I wrote for Kona 2019, where we were trying to sort of make sense of exactly what the contract's proposals, how contracts should behave and what they should do. And one of my coworkers came up with, well, it really boils down to, there's just five possible things it could do. And now we've sort of boiled that down to just four since then.

When you have a contract check, so you have some predicate that needs to be true, you really have choices like, am I going to try and see for sure if it's true at runtime or not? And then if it's false, am I going to continue into the code that follows even though there's been a violation or not? And so given those two binary choices, you really get three or four semantics depending on how much you understand undefined behavior. So if you're checking it, we call the case where you, if

there's a violation, don't allow the program to continue, we call that enforcing the contract. That means you check it. If it's true, great, everything's fine. All these semantics should basically all do the exact same thing when there's no contract violation. It checks it or doesn't check it, and then code continues normally, because that's what you want your program to be doing all the time. You want your program to be correct. When you enforce a contract check, you want to say, hey, compiler, please make sure that no matter what, if there's a violation of this predicate, if it's not going to be true, stop the program. Don't let things continue. I don't want to ever run my program after this with this false.

That's sort of the same behavior you get with C-assert when it's on. Your program aborts if there's a violation. The next semantic is when you say, I want to know if there's a violation. I want you to determine it, but just tell my violation handler it's happened. I'm going to maybe log something. I want to follow up with it afterwards, but then I want program flow to continue as normal. And this is sort of the only viable way to introduce new contract checks into old programs, because you often want to say, I have a program, it's out there running, it's great. It's not checking contracts, because C++ did not give me a my contract check? What if I have a bunch of bugs that are just latent and not actually causing problems? I don't want to deploy this to my production systems and suddenly have to spend a day with everything crashing until I can recompile and redeploy a new version that doesn't have those contract checks. So there we really,

we want the observed semantic, which is what literally lets you say, hey, I really want to know if my contracts are being violated, but other than that, don't change my program. Don't abort it. Don't kill it. Don't terminate, let it keep running. I'm confident that's okay because it was running yesterday when I had the contract checks, not in the code at all. The other cases, the other sort of easy to understand semantic is ignore, which is where you just do nothing. That's the, the C assert case of where it just gets compiled out into nothing. We still want the contract checks expression to be sort of semantically validated. It doesn't get compiled out so it can be completely invalid, but we don't want it to impact sort of what we do at runtime.

And the last semantic, which we are not proposing as part of the MVP, but which sort of fits that, we have two binary decisions, the cross product of two binary decisions gives you four possible choices, is the assume semantic, which is where you say,

I don't want to check this at runtime. I don't want to evaluate it, but I want to assume that I runtime. I don't want to evaluate it. But I want to assume that I never pass this when it's false, which is basically saying I want to make it undefined behavior to continue past this check when it's been violated. That's sort of the semantic you actually get with every standard library function on all of its preconditions because everything in the standard library preconditions are sort of defined as it is undefined behavior to call this this way to

call this incorrectly um and that sort of completes completes the square of possible semantics but we at sg21 we sort of early on came to consensus that we do that we want to focus on the safer sides of contracts as a feature and not make it an arbitrary tool for introducing undefined behavior until later. So the MVP will not include assume as a semantic. But I sort of hope your favorite compiler vendor will introduce it for you and that we will get experience using it and then come back to the committee and go. It really fits the complete picture and should be part of that. So you said compilers, right?

So we have three semantics that will be in the MVP, absorb, enforce, and ignore, right? Yes. But how do you choose which one you get like so what's the what's how can the user tell the compiler okay i want to ignore this or i want to like enforce this so so this was the very nice i think evolution that happened just in the last sort of month or two which is that we have now made this something that is completely implementation defined. The compiler is sort of required to pick one of those three semantics

somehow. And when it evaluates the contract check, it's going to pick it and either ignore it, enforce it, or observe it. But how it picks it is up to the compiler is an agreement between you and your compiler as to what that's going to be so i would expect compilers will all give you turn all my contracts to enforce turn all my contracts to observe turn all my contracts off um i would expect compilers to give you hopefully more granular choices than that like turn them all on for this translation unit, but not this one. Turn on all my precondition checks, but leave my post-condition checks ignored or my assertions ignored. I think there's a wide variety of flexibility now in what compilers

can choose to give to people in terms of how they flip contract checks on and off. They could, in theory, go to the point where you say, I want line by line to be able flip contract checks on and off, they could, in theory, go to the point where you say, I want line by line to be able to flip them on and off using some configuration flag I pass on the command line. What we don't have is the ability to encode additional information on a contract check saying like, hey, this contract check is of this type, like it's new, or it's really expensive to calculate or something like that, which are all things that you know when you're writing a contract check that can go into that decision-making process. But I think that's a post-MVP feature that I think needs to build on top of this. But right now, it's basically going to be up to compiler vendors to

tell you what flags they have to control this stuff and give it to you. And I think that leaves a lot of flexibility in their hands and different compilers will do things slightly differently, but I think it should be very clear what basic choices you have available to you. So getting back to the bike shed, what about the syntax? What's that looking like now? Is that being nailed down yet?

I don't know if we're going to nail it down successfully, probably until Kona, but I think we are aiming to publicly figure out how we're going to figure out what a viable syntax is and which one we prefer as a study group. I think right now the only sort of fully viable syntax I've seen is the attribute syntax that we had in C++20 contracts. It has a number of features that sort of subtly allow it to be sort of extensible without having to worry about a lot of things. We know where things would fit. It also has downsides in that it follows the spirit of what an attribute should be, but not necessarily the letter of what an attribute should be, which I know is near and dear to Timur's heart. But to be fair, they're not attributes, right?

Because the way it's looking in that proposal is you have double square bracket, pre, post, assert, and then a colon, which is something that you can't have on a real attribute. Yeah. They're like attributoids rather than actual attributes. Oh, I like that term. It's the attributoid syntax. I think we should... That's a paper title. The attributoid syntax. I'm going to give you an attribution for that. Yes. I think, again, syntactically, they're not attributes.

But I think at the end of the day, if you ask the average C++ developer in a world where that lands, are contracts attributes, they're going to go yes, because they have the double square brackets. I don't think that subtlety will be obvious to most people. But if that convinces Timur to accept the attribute syntax because it's not really an attribute, great, because I think that is a source of friction in accepting the attribute syntax and that it doesn't meet the spirit of what we seem to be agreeing on the committee of what attributes should be. We don't really have an alternate

syntax that I think provides the same flexibility. And I think we need to figure out if we can formulate such an alternate syntax that is not an attribute syntax that meets the same requirements and lets us have all the flexibility the attribute syntax gives us. And if we can do that, then we sort of flesh it all out. We have two papers to look at. We can sit them side by side and then vote. And whichever one has more consensus wins and we move on. And that's sort of my hope

for the next like six months is to see that happen. Well, let's see how it goes. I'm definitely very curious what we end up with. I'm trying to stay as neutral as I can in this debate and just kind of help people find consensus.

I do see the appeal of the double square bracket syntax it also has already implementation experience gcc has implemented it but also i've heard a lot of people who were seeing it for the first time just say it's ugly you know it's not really a technical reason but it's just yeah this is ugly it has these double square brackets right and there are ideas of doing something like pre uh kind of brace or pre-paren, but then it's kind of unclear how that would work with all the cases that you want to support.

Yeah. That's sort of why I want to see a full... Figure out the stuff we want to do with this syntax and then see what it looks like, because ugly is comparative. Ugly is not... This is is ugly we must do something different doesn't mean you're going to get something else that's not uglier right if like if i and again if it if you get 25 people voting and like 10 of them think one is ugly and 15 of think the 15 of them think the other is ugly, the consensus building process is to go with what those 15 are saying because it has more consensus. And at the end of the day,

without a proposal that everyone thinks is pretty, that's really our only viable path forward. So I think my personal number one criterion would be that you could show contracts with whatever syntax we should choose to somebody who has some c++ experience but has never you know been exposed to standard contracts before and they look at the syntax and they say oh yeah this probably does this you know this it's probably this is probably what this does this is probably how i would use it and then you know they would go ahead and guess like what it does or like how to use it and they would be right right it should be like kind of something intuitive and i think looking at some features that we standardized in the past like coroutines or modules which you know take a lot of boxes in

terms of uh use cases but the learning curve uh especially with core routines as phil knows because you've done quite a few talks on the subject is extremely steep right and um i mean syntax is probably not even the most relevant aspect of this but i think i would like the syntax to be helpful there like that you can look at it and you just know what it means and it kind of fits into the language i think yeah obviously it needs to support all the things that we needed to support but i think that's kind of in my personal opinion the number one criterion because i'm really worried about all of this talk that you hear that c++ is getting more complicated that you know you come up with all of these features that are like over engineered and so i don't want contracts to be that yeah i mean do you feel the attribute syntax meets that criteria because it doesn't

seem to me it doesn't seem it it is different enough to call out like this is something different like i'm a little wary of the ones that just look like a function call the syntaxes that might just look like a function call because it's not like that expression is not necessarily evaluated at all which in other than a size of operator application generally isn't the case when you see something with that syntax so i think the attribute like the attribute syntax calls that out as like here's an expression it's a little bit it's going to be treated a little bit differently than it would be somewhere else does that seem learnable to you or well too different i'm not sure that you know people will know that the colon means it's not an attribute because i

know because i've worked on attributes quite a lot that an attribute standard attribute you have like double square brackets then you have the uh attribute uh name and then you have uh parens and inside the parens you have a balanced token sequence right and if the parens are not there then it's not an attribute but i would think that the vast majority of css users doesn't know the exact like grammar definition of attributes and they just see double square brackets and they decide oh it's an attribute so i'm i don't think i'm i'm really not convinced one way or the other and maybe it will turn out that the attribute syntax is the way to go but i i i'm a little bit skeptical i want to kind of do this this whole analysis of like okay what what

what requirements do we actually have for the syntax and which of the ideas that we have actually fulfill those requirements you know and then see see what viable options we have and then you know compare them and again i i have many use cases i have certain use cases for contracts i want to make sure that long term i can support like in particular my day job is supporting a contract checking facility that we use within Bloomberg. I eventually want those macros to just be things that expand into whatever C++ contracts let them expand into, and I then have to stop supporting the guts of them, and it all integrates with all the stuff we've been working on for so long.

And so my primary horse in this race is to see that happen whatever syntax it is i don't i don't particularly care that much i want something that people like and agree on and then but that meets meets the needs i needed to have um yeah i think i'm really with you there because i think every framework super sauce framework I ever worked on had some sort of contract facility that is a little bit better than Assert, even though people wouldn't call it that necessarily. But there's always some more clever Assert macro that is configurable and does something more than C-Assert does. And I'm pretty sure every framework has that, or at least every one that I've ever worked on. Maybe not quite as sophisticated as what you're doing,

but at least more than what C-Assert gives you. But I think really what we're missing is to be able to do this across libraries and across code bases and across API boundaries. And that's kind of the big thing that we're missing to agree on an ecosystem way of doing this. Yep. Again, that was the primary motivation

for Bloomberg bringing contracts proposals to the committee in the first place was like, we want libraries that are doing contract checking to, when they fail, fail the same way that our contract checking facility fails so that we can get logs in the right place and know what the problem was and address them all in a uniform way.

I think that that is huge for an enterprise to be able to take third-party libraries off the shelf and deal with problems in them the same way they deal with problems in their own code so we've spent about the last six or seven minutes i think talking about the the syntax of a future feature on audio only podcast so i think maybe our listener has a point about being a bit too esoteric at times. So we should probably move on to something a little bit more concrete. I think that the violation handler, we haven't touched on so much yet, and the connection with the LACOS rule that we talked about earlier on.

Is there any more we have to say about that? So I think that the connection with the LACOS rule can be non-obvious. I think that there's really two primary use cases, and both of them are enabled by having a custom contract violation handler, which is, I mean, both of them involve, I want to check a particular contract and have it throw if it's violated. One of the ones which I think Timmer independently discovered is testing. You want to test every line of code you write. Contract checks are a line of code you've written. You want to make sure that they're doing the right thing, that they're going to detect certain violations, and that they're going to not detect or not scream when you call a function correctly. The not scream part is fine. You run your unit test with your contracts enabled. If they pass and your contracts don't say

that there's a problem, you're good. But the other side of, I want to make sure that this is going to catch certain problems when enabled, we call this negative testing in Bloomberg, is harder to test. And one easy strategy to test it is tell your contract currently macro or whatever. If there's a violation, throw an exception and then call your function with invalid input with this with it configured to throw and then catch that exception.

And if your function throws that exception, you catch it. You go, great. I have negative tested this successfully. And if not, you go, I have failed my test because I tried to call square root of negative one and it returned normally, which is gibberish because it clearly couldn't have returned the square root of negative one when the return value doesn't support an imaginary value. So this sort of negative testing is sort of one common use case. And it depends upon being able to say to whatever your contract checking facility is, when there's a violation,

I don't want you to abort. I don't want you to do something else. I want an exception thrown. And with what we just adopted in SG21, you can now write a contract violation handler that does that. It throws an exception and that will propagate up normally, but not on a no accept function because then it will hit the no accept and you'll get an abort or terminate called and your test will fail gloriously even though it was meant to succeed and catch that exception. The other common use case is people who want to say, I am running this program. I really, really want to not terminate my program because terminating comes with too high of a cost. This comes up in things like I'm writing code for a pacemaker. Like terminating might not be an option or terminating might literally lead to someone being terminated, which isn't good.

I want to be able to limp along understanding that I might be in a bad program state, but I need to be able to continue in some fashion under all circumstances. And in those cases, you might want to install a violation handler that says, I'm going to throw an exception. It's going to propagate up the stack. Something at a higher level is going to go, oh, my contract violation exception happened. I'm going to throw an exception. It's going to propagate up the stack. Something at a higher level is going to go, oh, my contract violation exception happened. I'm in a really bad state. I'm going to start to try to clean up the pieces and try to get back to work, understanding that you may be in a very corrupt state, but you may also not be and be able to recover from that exception and keep going. So just to be clear, this gives you a way to say,

okay, here's a function, the preconditions have been violated, so I don't want to go into the body of that function anymore. Because otherwise, you're going to have language UB there at some point, right? Very likely, and you don't want that. But you also don't want to terminate the program. So you want to have some way of saying, okay, I'm not going to go into the body of that function, but I'm going to continue elsewhere.

And this is exactly what the throwing violation handler gives you. And this is exactly why we need the Lakers rule, because if you then put noexcept on that function, then you get the terminate, which is exactly what you don't want. One comment on this, by the way, the first use case, which Josh said, I independently discovered. I remember when I was doing this, I was at Cradle and we were like trying to figure out how to test our code and i stumbled upon this because i was using catch 2 which is your framework phil and i was like okay i have these assert macros and i

want to test that you know the assert macro has been hit that that i didn't forget to write the assert macro because if it's not there people are going to introduce bugs right but then i remember like i told i asked you how to do this in Catch, and you were kind of saying this negative testing stuff is kind of not really within scope of a unit testing. I was like, no, I don't agree with you there. I think this is something that people should be doing. Have you changed your mind,

or have I maybe misunderstood you completely there? There's a little bit more to it than that. Catch does not support what are called def tests, which some other frameworks, notably Google Test, do, which will actually fork the process and then detect the termination while still obviously running the parent process. There's obviously an overhead to that, and so I know one of the complaints is, well, you can do that,

but it's not actually feasible at our scale so that may not be enough but that's exactly why you need the lacrosse rule and the throwing violation and that is exactly the reason why there's no solution that i've seen other than you know proposals i'm bringing in the far future that handles all cases because there's a phrase most people have never even considered which every time i bring it up to someone goes like huh that is a thing i should consider which is you need fork safe code to do death testing that's going to fork and then violate like even that doesn't cover all cases and there's a lot of not fork safe but like anything with concurrency anything where you're starting other threads is generally not a fork safe component that you can

you know do that kind of death testing on so death testing handles skips sidesteps the no except problem but gives you a different set of problems that you don't often think about similarly like the exception thing the exception doing it with exceptions hits smack in the face of no accept and will fail miserably but it has handles most of the other cases where you where you can call the function and it's not no except so there's a lot of there's no perfect solution that is available to us today. I think no comprehensive solution might be the better way to put it.

Yes. There's no solution that can test all possible preconditions on all possible functions. Which is fine. Yeah. And the scalability one is why the death testing

is really not viable for many use cases. We test occasionally millions of combinations of negative testing, and with death testing, that would turn a unit test that takes seconds to complete to one that would take hours and just not scale, not be viable. But it stopped becoming unit test at that point just to complete that circle though one other approach that again doesn't cover all cases

not comprehensive but uh i find it's very useful a lot of the time is to externalize the the condition that's being checked so the thing that says are these inputs valid have that as a as a separate facility that just returns a billion you know is valid and then the same thing that checks returns a billion, you know, is valid. And then the same thing that checks at a contract level within the function, you can check in your unit test as, you know, does that check actually work? Yes, I think that that is,

that's sort of the road I want to go long-term with the MVP or with post-MVP contract facilities, which is provide a way to explicitly say, return to me either a contract violation or nothing if I try to call this function with these arguments. I think doing it manually where you just say, I have separate preconditions, always opens the gap of, well, did these get out? Did these skew? Did I change the preconditions always opens the gap of, well, did I, did these get out? Did these skew? Like did I change the preconditions in the function, but not go change my unit test to call the new preconditions. So again, there's that works if you're, but leaves more stuff you can get wrong in the testing process that you don't

have that, like you're not actually testing that your functions on precondition checks are right you're testing that the separate function you're calling is this is not violated and hoping that that is the preconditions that are actually checked by your function yeah that's more i could say there but i think we're on a tangent off a tangent rabbit hole we can go down here i would just say say that I have a paper, P2831, which lists, I think, eight different ways to do this negative testing stuff.

And my conclusion is the best way and the most scalable one, obviously, is to just throw in an exception. But there are other ways to do it. Okay, well, we are running long. We did just want to see whether there's anything you are working on within the committee other than contracts before we finish up. So one of the other things we're really trying to get

from our library experience at Bloomberg into the standard is trivial relocation, which is sort of this ability to end the lifetime of an object and start a lifetime of another object as a single operation where all that operation needs to do is mem copy. And the amusing thing is that the 90% case for types is that they are trivial when they relocate. Like anything that just owns external resources. If you promise not to destroy the source object and you are going to transfer ownership and it's just a bunch of pointers to things, to a new object, all you have to do is bit copy everything over and then just throw away the old

object completely and you're golden. So trivial, trivial location covers the vast majority of types. And if we had a way to express it and make it well-defined to create a new object just by memcopying it for something that is not trivially copyable, suddenly your vectors could be doing this when they move things around. And every time we get a significant improvement in how a vector moves things around. We see huge performance gains in sort of all C++ code running everywhere. So we're trying to get that there. And as part of that, we've attempted to also answer the more fundamental question that everyone asks when they see this was, or many people ask, which is you've got trivial relocation,

you're proposing, what is relocation? What does that mean? Because you want a trivial version of something that you're not then defining. We don't have relocation as a first-class thing the same way move and copy are in the language. And I think we are trying to make that happen, or at least give people an idea what relocation is. There's another proposal that's similarly trying to go down that road. And my hope is that that starts to get consensus as a long-term plan and that people look at it and go, well, trivial relocation fits into that

and we should get trivial relocation as soon as possible. And relocation can then build on top of that because trivial relocation is a bigger win in many ways for parts of it. So that's one thing we have in progress. And then lots and lots of discussion of the LACOS rule in many different contexts. That was sort of the other big committee-related thing that I get involved in and pulled into. Right. So Josh, last question. committee-related thing that I get involved in and pulled into.

So, Josh, last question. Is there anything else happening in the C++ community right now outside of all of the stuff that you're working on that you find particularly exciting or interesting? Is there stuff outside of the committee? I'm not sure. It's hard to poke my head up and look outside. In my spare time, I'm trying to write a book on allocators because that's technically my day job right now. Although I keep getting distracted by writing papers about contracts instead.

So you're not able to allocate enough time to it? No, it keeps getting paged out, but it will happen no matter what. Because again, my group PMR allocators evolved from a Bloomberg proposal, and I think there's a lot of misconceptions about how to use them, how to use them right, and things we've learned about using something morally equivalent to them over a long time, and we want to get that out in the wild well thanks very much for for being on today uh anything else you want to tell us before we let you go no thanks for having me it's been great i think and anywhere that the people can reach you they want to find out more um if you find any of my papers my bloomberg address is on them i don't do twitter or other real widespread social media so very wise email me if you want to contact me that's really the easiest way all right awesome well thank you so much josh again for being a guest today i think

it was a lot of fun to talk to you thank Thank you. It's always fun to talk to you guys too. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in. Or if you have a suggestion for a guest or topic, we'd love to hear about that too.

You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow cppcast on twitter or mastodon you can also follow me and phil individually on twitter or mastodon all those links as well as the show notes can be found on the podcast website at