C++ Club - WG21 October mailing, Carbon, Cpp2, Safety

Episode Date: November 1, 2022

With Bjarne Stroustrup, Gianluca Delfino, Ashod Nakashian, Vladimír Arnošt and other colleagues.Video: https://youtu.be/k8K-ZlFt6IgNotes: https://cppclub.uk/meetings/2022/155/

Welcome everyone, this is meeting 155 and today is the 27th of October 2022. We've got some feedback on YouTube. This comment by Iceman says, one thing I don't like is that you guys always seem so pessimistic about new things that can be a part of C++. I'm not talking about carbon or other garbage trying to replace C++. I'm talking about CppFront. I think it's a nice effort from Herb doubling down on C++ and fixing the language. Why are you guys like this? And my reply was, I say what I feel, and I'm being cautious. I think CppFront is an interesting experiment, but it doesn't fix C++ in any meaningful way.

Instead, it forks the language and splits the community effort without providing any certainty. Coming from the committee chair himself, it worries me. It'll be interesting if it succeeds, but we don't even know what would a success be like with CPP2. Yeah. To which they replied, that is a fair point. To be honest, I think I was a bit too swayed by Herb's talk. Shows he's great at talking about things, I think. But yeah, I myself have not written a single line of Cpp2 and I don't plan on writing anything soon. Let's say I was also being cautious, just subconsciously. So yeah, the excellent presentation skills that Herb has certainly did have an effect on many people, I guess. He's a very charismatic presenter.

Indeed. It's us, crusty, pessimistic, old... Yeah, we are grumpy. Grumpy people who are not easily swayed. Yeah. Well, I think it's always healthy to provide some degree of pessimism when everyone is ecstatic about new things, just for balance.

We are grounded also, not just... Let's call it grounded. I like that better. Right. Next one is a short tweet, which I call the two legends. John Romero tweeted, quote, incredible life achievement unlocked. I spent an hour of one on one time talking to the amazing Bjarne Stroustrup about C++ at the conference. Yeah, I think everyone knows who John Romero is. I played countless hours of Doom in my younger days, and to think that at last he met the one person that sort of made it possible by creating C++, which was the foundation of Doom and every other big game, I guess, since then. It's nice. Someone says,

Very nice! I remember his C++ book was considered a bible at the Polytechnic. Out of curiosity, did he know who you are to it john romero replied we didn't talk about me at all i'm just a puddle of slime sliding around on the ground compared to him kids when you meet your heroes do not talk about yourself ever you're wasting that precious Very, very humble John Bear. That's a good quote. Indeed. And there were some more pictures of them meeting and talking. And I must say, I feel pretty lucky myself, having talked to Bjarne and sometimes meeting him again in our meetings. I still can't fully comprehend how lucky I am to have done that. Right, on to the next topic. The big October mailing. The committee mailing this time has 80 papers, and of those, 41 are at revision 0. Let's just quickly go

through them. Some of them, obviously, not all of them. So this one is an updated document called Direction for ISO C++ by Howard Hinnant, Roger Orr, Bjarne Strøgstrørup, David van de Voorde, and Michael Wong. The additions to this document are highlighted in red. You'll shortly see what that means. There is accent on type safety and static analysis. And let me scroll to the highlight. You may have to squint a bit to protect your eyes. When they say red, they do mean red. I thought it was going to be red text, but instead they made a very saturated red background.

I'm going to miss that. Yeah, no one's going to miss that. To me, this looks like a response to all the efforts of Carbon and CPP2 and other related activities and comments have been surfacing lately. And they start with this quote. Recently, there has been a lot of discussion about safety in the context of C++. Given the increased importance of safety and security in the world, we consider improved safety an important priority for the evolution of C++." And then they explain what they mean by safety, type safety and static analysis. They finally say in this

paragraph, quote, in addition, we encourage continuing work on language and library facilities that increase various forms of safety. Examples such from the past include range4 and stdarray. So that was it for the additions to this document. We'll see more documents that you could see as responses to these external efforts. The next document is by Ville Vutilainen. It's called To boldly suggest an overall plan for C++ 26. This is revision 5 and I just wanted to double check what is included, what's supposed to be included in C++ 26. So the plan is still work towards having the following things execution, more ranges work, and reflection.

Unspecified ship vehicle is for contracts and pattern matching. I'm kind of disappointed to see pattern matching not explicitly targeted for C++ 26 because of all the new proposed features I think pattern matching would have the most impact on the code I write, for example. Is there a design already set for pattern matching or is it debated? There is an updated document that we'll see slightly later, which is preparation for discussion about it in the committee. And there are sort of two approaches that are compared in that document. I think Michael Park is still working hard on the proposal, but apparently there are some unresolved questions.

I hope it has a chance, because I would hate for it to be delayed till 29. 29 seems like a big number, so... Yeah, a bit scary. I'm really happy that we're gonna get reflections, apparently. That's a very long time in the making. Yeah. to get reflections apparently. That's a very long time in the making. Regarding execution, Ville says, during the C++23 cycle we made good progress on senders and receivers. There is however more to be done in this area, such as more sender adapters, async scopes, and async streams. Does it mean that we decided sender and receiver is async scopes, and async streams.

Does it mean that we decided sender and receiver is the way to go? I think so, yeah. I think that's the way, that's the async model for the future. Interestingly, he says, regarding coroutines, I think, where's library support for coroutines, which was in the C++23 plan? He says, while we can still expect to see proposals for a task type and other such specific things, the execution proposal P2300 covers generic library support for coroutines and knits them into the generic asynchronous framework provided by 23100. So yeah, that's an additional confirmation that senders-receivers is the way to go.

Regarding networking, he says, the earlier direction approach for networking didn't have consensus to a fair extent due to concerns about the composability of the approach. We don't have a composable approach proposal at this point." And basically, if that comes, there'll be discussions about it. But it looks to me like all the existing networking proposals are pretty much dead in the water. This doesn't even mention the safety issue, how do you update sockets, whether there is new standards, you know, if you want to do SSL and this kind of stuff, which was on top of all the other problems. Now, not in this document at least, this is a very high level one. So maybe there will be some updates to the existing networking proposals. Yeah, I do wonder what's going to be of that,

because we have still design issues, and we still don't know how we're going to approach updates if there is the need to update something quicker than a three-year reschedule. That's a very good point. Core routines is suffering from something very similar right now. It seems to be an implementation in the standard that depends on external library implementations. And there seems to be this hard dependency on TBB or whatever they chose on.

And something that's already bad, right? But I agree for networking, it's gonna be even worse because you can't control the internet standards and the security issues that they find and they have to patch them immediately. You can't tie that with a standard that has a three-year cycle and a relatively slow compiler release cycle. I think that's going to be something of a nightmare. And probably the solution would be what they did for coroutines,

which I find very annoying and disappointing, which is basically going to be, yeah, you're on your own. Just figure out which version of OpenSSL you need at runtime, and you will need to figure out how to find it and link it. And I think that's a mess. It's neither leveraging the advantages of having an ISO standard, nor is it leaving you to come up with your solution. It's forcing you to live in this middle place between the standard and practical

you know runtime requirements and again i don't really know what would be best it's not clear to me like at this point keep some aspects like networking outside of a standard would be an option. Like, okay, don't worry about it at all. Just have a library or something. And then we get back to the package manager conversation. So I don't know. They could do something like we did with threads, right? I mean, the threading model is built heavily around the P threads. It kind of implicitly assumes that you have some,

you know, lowest common denominator implementation that's POSIX compliant that we know, you know, even Windows is more or less compliant with. And that's what they started with. I think that's a good and reasonable starting point. So they can start with the Berkeley sockets as a good foundation. They don't have to implement any of the protocols, any of the SSL stuff, right? So you would have, just like the threads, bare minimum infra to build upon. And then you can add more bells and whistles

and you can do your own thing or use ready libraries that would be compatible with it. So it starts without SSH and without worrying about the security. Without HTTP, without SSL, without certificates and all that mess. I really would hate to see something like what they did with coroutines, which is just your code may or may not compile depending on what other third-party libraries you have installed and it may or may not crash during runtime

depending on which version you have and which version of the compiler you're using. I think that's a mess, right? It's the kind of thing that first experience is so bad that people just stop trying. And they kind of get this very bad impression that, okay, this language is broken or this system is broken and they stop trying or using it. It's not the thing that you can improve on later, right? Somebody who's using coroutines, for example, is either going to be locked into it and they're going to figure out what's reliable and they're going to use that and they will try to avoid updates or changing it.

And another group is just going to say, okay, I can't use this. This is just too much work for me to figure out which version of which library I need. And is it going to be compatible? Is it going to support upgrading the compiler and so on? So I rather they hold off until they have a plan rather than they do this. And for networking, I think it's 10 times worse. And I say this having written a good number

of these protocols myself and having used OpenSSL and others. It's real pain, even when you don't have the standard to worry about your own. You can basically do anything you want. You can upgrade at will and so on. It's still very painful, very problematic, very difficult. Yeah, mix the compiler. I think you have a lot more problems now.

Yeah, it's hard. The networking TS proposals have been in development for years, and we've discussed last time that there was a new one regarding network security, but it's not compatible with senders-receivers because of some serious reasons, and also the two opposing sides, so to speak, senders-receivers and the networking TS, they seem to be very hostile to each other for whatever reason, very territorial. And that doesn't bode well for the future of networking in the standard. We're all losers after that. Yes. Or you can just use ASIO, which most networking TS people use

and what serves as the basis of networking TS. Pretty much at this point, I think the community has been using ASIO, either boost or non-boost from 17 whenever there was split. But yeah, it's not ideal. And yeah, it's a very good point that network security in the standard would mean that it wouldn't be able to be updated quickly enough for any security vulnerabilities and updates that come out. So that's also a risk. Right, so the next

paragraph in this document was, what about linear algebra? And Ville says, BLAST-based linear algebra is making good progress. It doesn't seem to need a special scheduling priority and can be dealt with as an extension almost like any other. Hold that thought. We'll see about that slightly later. Also, it could be another one of those that the day after it ships, there is a newer version that is

faster, and everybody would like to break the old implementation. And then we'll have people complaining about not being able to do an ABI break to improve it. Isn't this

a good example of a dubious topic for standardization? First of all, what is the percentage of the user base that's going to benefit from a Blast library? Second, why is it something that necessarily needs standardization? Right? Third, are there not other higher priority, more useful challenges for the language and

the committee to focus on before they free up their time for something like this? And finally, aren't already like good industry standards that i guess you know hpc people already know about and use sounds like a little bit weird to me that this is a focus for 26 i think this is being actually, I'm not 100% sure, but I think it's being pushed by exactly those people, HPC and gaming. And if they say they need it, they need it standardized. It's quite possible that that's the case.

I do hope that maybe they're able to work in this in parallel because being this kind of a new addition doesn't have to fit between other features. So maybe it can be somewhat decoupled from the rest of the work. And hopefully it doesn't take too much time off of people in the committee that something else wouldn't get in otherwise.

But all the other points are valid you know it does this i don't know does this belong in the setup maybe maybe as glad said you know if they argue it maybe it could be i certainly wouldn't have a problem with that just that you know how would you update it that's always the same problem i don't know it's the the same. Sorry, Gleb. No, no, go on. No, yeah, it's the same. Every time there is such a proposal, very much like the graphics proposal. That's the one.

It's always like this, you know. Should we have this as a package? If we had a package manager, yes, this most likely wouldn't be a proposal for the standard. But we don't, so we're living in a strange situation. That's a good point. I mean, they can always have technical specifications for this kind of thing and have it as a separate add-on. But again, I'm not sure what they're going to standardize.

Is it going to be the interface? I mean, maybe, but the problem with things like this is that this is really performance-sensitive stuff, right? The only reason that you would need to worry about the implementation is because you care about performance, because you're doing something that heavily needs these transforms and all of that representation in

memory. So it's typically, you'd find that the hardware manufacturers themselves actually have, like AMD has a Blast library and Intel has a different library. The reason is obvious. It's because they're optimizing for their own hardware and their own memory latencies and other concerns as the cache size and so on, right? How well is the prefetch are going to work in this case versus that case? So the problem there is that the interface often is a slave, if you'd forgive the expression, to the performance requirements. It's not the other way around. The interface isn't designed to be beautiful. It's designed to leverage the performance aspect to make things fast, right? So you can't really be copying objects around. On the contrary, you need some sort of references and access to the data directly and do things on a very low level with pointers and strides and things like that.

So, again, I'm not sure how they can standardize something that's heavily dependent on the hardware and the technology of the hardware. I mean, the architecture changes a little bit. They might modify them. I mean, why not? So, again, I have serious doubts about these kinds of initiatives and who's going to benefit from and which library is going to get the upper hand and get standardized.

And as I say, there are a few of them that are fairly popular and it's not obvious to me that any one of them is the obvious choice yeah i guess we'll see the next paper is a small one and it's mostly committee procedural stuff it's called a call for for a WG21 managed chat service. And it says that Slack has been a useful resource within SG16 for collaboration, informal sharing of ideas and news, and discussion of controversial topics. But there were some concerns of the lack of enforcement of a code of conduct, and that prompted several attendees to deactivate their accounts.

And so at the moment there's no sort of an official chat facility for the committee members. And given that we live in the strange pandemic times, it's always good to have some way of informal communication without having to go face to face. So they chose something called Mattermost, I think. I don't know, some chat. But there were some amusing examples of anticipated usage, and I will quote one of those. That's the reason I included this paper, actually.

An example of informal discussion within a working group or SG. Amber Ambitious. I'm writing a paper that proposes adding a YITSitz facility and I'm thinking of calling it Fazuzel. Is there a better name? Peter Pidant. Fazuzels do not equomber. I think what you are describing is a Zasnich. Cora Correcto.

Whether the equomber is conditional on the rucks. She has it right. Yeah, an example of very productive in discussion. I need this yesterday. I need this yesterday, yeah. Right, next one is vector API for random number generation. I wanted to mention this because it would basically allow you to generate a bunch of random numbers into a container, and that would increase the usability. But unfortunately, I don't see that it addresses the long-standing issue of

proper initialization of the random number generator. There is an outstanding proposal which didn't make it into C++23, and I hope that it makes it into C++26, because otherwise most of the code floating around that initializes random number generators is wrong. What was the issue? Do you remember? I think it's because of some different sizes of integers that are used when initializing the random number generator, which makes random numbers not so random.

And the proper initialization is like a sizable chunk of code, and no one does that. And would fixing this qualify as an ABI break? No, I don't think so. I think they just ran out of time. Are you referring to the fact that most initialization is done by a literal twister is 64 bits, so you would actually need to provide 64-bit entropy? Something like that. I don't remember in detail, but I think that's the gist of it.

There is a proposal to address this, so let's hope we get it. So this is the proposal to add linear algebra support to the C++ standard library, but that's not the one that Ville Stiegel. So this is revision 7. This is a long-going one. There are some records of votes, so it's sort of progressing. There are some open issues. So this doesn't specifically say that it's based on any existing interface. So probably it defines its own API and all the data types. This one is the one that Ville mentioned. It's called a free function linear algebra interface based on the BLAS. This is version 10 actually, more than the previous one. What's curious is they specifically mention differences with other libraries. They say this one is interoperable with other linear algebra proposals. And the difference of this

one is that the set of, this is a quote, the set of linear algebra operations in this proposal are derived from a well-established, oh, Piana is joining, derived from a well-established standard set of algorithms that has changed very little in decades. It's one of the strongest possible examples of standardizing existing practice that anyone can bring to C++. Hello, Vyana. Hi. Thanks for joining.

We were just talking about some papers in the latest mailing. It's quite a lot. Oh, I see. And we mentioned the paper that you co-authored, the direction of RISO C++, with the highlights in bold red. Oh, yes. Yes. So we reckon this is a response to all the stuff that's been happening around carbon and TPP2.

Yeah. And some of the comments about safety in the Commerce Department and other places. There are a lot of people who think that safety is the only thing, and they can only get it from a new language. And in fact I think I have started to mention those specifically when he introduced this CPP too and so the first thing he said was the government wants us to do something about it and a Lot of people got scared

Well, a lot of people saw the opportunity to get their ideas pushed I See a lot of things we've heard before that didn't get traction now coming back. I wonder if Microsoft is reacting to Google or they both had the same idea around the same time and had something prepared you know in hiding i don't know um i don't think google has ideas people at google has ideas i don't think my business ideas it's people at microsoft that has ideas and you have to distinguish that. If the corporation starts pushing products or basing products on something, you could say that the corporation is in favor of something. But when it's just people talking,

it's very hard to know what is real and what's personal projects and what's spare time projects and things like that. Fair point. People tend to forget that and they just see somebody at organization. They think that organization is going there. One thing I learned in the early days of C++ is that every major organization has at least one project in every new language. So the standard way of advertising something new is to give the list of 100 organizations that are using it. It means that 100 organizations at least has at least one person

experimenting with it. Calibration is hard. I'm not saying that people are not interested. I'm just saying you can't use it as a proof. Marketing is hard too. I guess this is one way of marketing. Exaggerate the apparent... Powerful way.

Maybe dangerous also. True. Yeah. But I do think that most of the recent novelty languages came after or peaked, their interest peaked after the 2019 CppCon conference talk from Chandler Carruth, where he publicly denounced that Unique Pointer was not as performance as it could have been. And then Titus Winter started asking for rbi break and but in the same time you could say that terb sutter has been working on his own thing for many years since i mean many years before and every conference would

introduce something else and herbceptions and the meta classes so there was a kind of a parallel independent train of thoughts. Maybe also getting the same wave after 2019 and maybe also coinciding with the RAS popularity increase. I don't know, there's been a little bit of a set of things stirring since then at least. Good observations. Actually, I just saw that Microsoft quietly released an update for Windows where, or maybe it's in the process of being released, where they rewrote the font parser code in Rust and didn't even advertise it too much. I'm sure the Rust people did advertise it. The Rust people are very, very good at propaganda. Far, far better than the C++ crowd.

For starters, they have an organization, which is a good thing to have for anything. Should I be worried about the done votes now? We are on YouTube now. Then if we say Rust people, you know, we may... Rust is a great language. Yes. Certainly we can learn something

from it. Yeah. So if we go quickly through other proposals. This is Hashembed, a scannable tooling-friendly binary resource inclusion mechanism that Jean-Huid Minid had been working for quite a long time. And the new thing here is that he says the C edition of this paper was accepted into C23. So hopefully C++ 26 will also get this. Yeah, I don't quite understand the set of problems this is addressing. I guess if you want to include a resource in your program, which is the case for many

game programmers, you could specify where to take it from and convert it to a set of bytes that you can access at runtime. Yeah. So, I don't know. Then you hope that you know what you are getting. Well, as with many things in C++, you have to know what you are doing. But here, what you're getting is not C++. It's not source text, I think, in many cases.

True. I think initially this was supposed to be a standard library function, std embed, but it turned into a preprocessor directive, which is I guess one way of doing it. It's another food gun, I suppose. This is just a way to, I guess, communicate with the linker and, you know, figure out a way to reference these embedded resources? I'm not sure because this wouldn't be a pre-processor. I think maybe this replaces the instances where in your tests you go look for a file

and you just import a file to read the binary content and you interpret cast or whatever you do maybe you don't have a test case, maybe you have some real world code that needs to rely on some binary to initialize itself and you don't want to bother

reading the file with a stream but I don't see why that would be a major problem. I imagine this is going to end up in the constant data segment in the binary, that it's not going to reference a file. That is definitely true, yes. Right, so it's... go on. This introduction provides some background. He says, for well over 40 years people have been trying to plant data into executables for varying reasons whether it is to provide a base image

with which to flash hardware in a hard reset icons that get packaged with an application or scripts that are intrinsically tied to the program at compilation time there has always been a strong need to couple and ship binary data with an application. So I guess there is a use case for this and there's been apparently some compiler-specific macros to do that, like this pragma stdc embed and something like that. I think this is just like a more standardized mechanism which allows you to avoid having to encode your binary to something like c array or c string so it's simplified to a build process but well it can't hurt really and then your resources really as uh i should mention just linked in and you get a symbol you can refer to.

So it makes sense. It's basic for embedded programming where you have no file system. You have to actually carry all your data with you. Yeah, that makes sense. Right, next one is pattern matching using is and as. This is Herb Sutter's paper, which I think is going to be also adopted into the pattern matching paper. And this has been revised. I don't know what's new in this revision, but I think that might be related to his CPP2 experiments. I think it's independent. I rather like this one. We'll see what the pattern matching group does with it. I think it is independent.

I should spend more time on that. It's on my infinite list of things to do that. It definitely has nice aspects. Pattern matching is a big deal. Yeah. We were just talking. I wish people would realize that. We were just guessing if there is a chance we'll get it in 26. I'll have to wait even longer.

One of the problems with all of these bright ideas floating around is that it soaks up time and energy and then things that I, and not just I, think are important doesn't move forward because people are working on their various personal projects, ideas that are not ready. Jan, do you think this particular paper will be pushed through only for better matching or would also come with this implication for casting? Because I think he wanted to use, you know, and I see you mentioned here that... I think he wants to use, and I see you mentioned here. I think he wants to use it for both, and I would be very disappointed if it came only for casting because I don't think it gives us enough benefits just as it stands. But as far as pattern matching, may give us a better pattern matching

and pattern matching is a big deal i like i like to have a pattern matching facilities in the standard i'm not sure i i understood well enough the way that he wants to implement casting and and ease and as instead of the many numbers of casts we have already so that I have to wrap my head around still the way I see it is that there's so many casts and most of their uses are doubtful. If you have the facility here, it will do the safe ones and it won't do the others. So it kicks you into caste territory if you want to do something that's information destroying,

whatever you call it, narrowing that kind of stuff just isn't done at the last version i looked at which means that you can use these fairly freely because they do the things that that doesn't actually damage the type system. Would the expert programmer, C++ programmer, still resort to the old, I mean, the usual cast? Yes. So this would be part of the safer subset of C++? Yes. It does the things that, for instance, I like to do and I have to do in cases,

but not the things where I know I have to be really careful. Messing with bytes is not what this stuff does. Thank you. Right. The next one is an interesting one. We've seen it before. It's an error propagation operator by Barry Revzin. It's the first division. I mean, second division, it's in zero.

And he says, this paper simply recognizes that there are many code bases that do not use exceptions and probably will not in the future. So CWolfPlus, he says, does not currently have a good story for error handling without exceptions. And he proposes an operator that could allow you to chain function calls when they return an optional or unexpected using an automated propagation operator. He gives an example of Rust. And for C++, he goes through several variants of syntax, like a question, question mark, then try as an operator, like in other languages, zig, swift, or like, for example, you call a function and then postfix it with question, question mark, so that the happy path

is preserved. So, yeah, it looks really weird. Yeah, I can't say I like it or that I wish it really well. We will see what happens. It does look weird, though.

You go like, who? Question mark, question mark. And the reader goes like, is it food? What does it mean yeah yeah just got rid of trigraphs and they're just calling back the other yeah bring back the trigraphs that'll solve this problem when he saw the trigraphs are gone he like, I was preparing for this my entire life. Here is the operator question, question mark. See, there's always surprising side effects from changes. Indeed.

So the next one is revision zero of this paper, Design Alternatives, Sort Type and Resource Safe C++. This is, by the way, very much an R0. There's this evening session, Future of C++ in Kona, and we felt that this work that was in progress and not quite ready had to be presented. So I cranked this one up rather fast. Yeah, so this ties into all these recent discussions and efforts, sort of a kind of response to that.

Yeah, I mean, people talk as if safety is one thing and they still talk as if some miracle cure will make the problems go away. A new language means we don't have any of the old problems except for the billion lines of code and necessity to interact with languages that doesn't follow those rules. So the question is, what are the problems and how do we deal with them? This is based on the core guidelines. Obviously, sorry, I shouldn't say the obvious. No, it is kind of obvious. The core guidelines are what everyone should be following, but not all of the developers do. No, not everybody can do it. One of the points is you can't convert enormous code bases overnight, which means that you are stuck in an intermediate state for years.

And how do you manage that the greatest complexity here is exactly that you're not going to get safety by sort of waving a magic wonder or your existing code if it's a mess of pointers and with no particular strategy for resource management and error handling, you're not going to get any of the definitions of safety, maybe with the exception of overflow, which can be done locally. But basically, you have to do something. And I expect that some areas require greater degrees of safety of various sorts than others. And you will start with those.

And you pay a higher price in code changes and strictness for those applications. There was another paper that had a title that read like a response to all these, this is the next C++. I liked this one, yes. It's by Gerard Waterloo and the title is C++ is the next C++. This has happened many times before, by the way. This paper is about providing certain attributes that would trigger specific static analysis for specific parts of the code. It kind of introduces subsets of C++ for distinct parts of your code base,

but on the other hand it could make it easier see it as roughly equivalent to the core guidelines profiles. That is, you name a coherent set of rules and then require that. So it's a different way of saying the same thing as the attribute that requires some form of resource safety in a cabinet micro-project. Yeah, the author of the paper lists quite a few guideline paragraphs that could supposedly be addressed by those subsets of static checks. So maybe it's not such a bad thing. The key here difficulty is to get a coherent set of loops so that you can describe in, well, a single sentence what it's doing. He does try to come up with such subsets like no unions, no mutable, no new delete,

and so on. No volatile, no C-style variadic functions. And the other interest... It's very verbose. But I'm all for it if this allows to move in parts of your code to... Let's say you would have a magic GCC flag that would enforce the core guidelines, which I don't think, unfortunately, there is. But there is something in MSVC, I think, but not in there.

The real problem is if you have a piece of code that follows the guidelines, that makes a guarantee, like no memory corruption. Now it is called by some piece of code that hands over a pointer from that code base, or if it calls another piece of code and hand over one of the safe pointers to that, how do you know that the code isn't, that the code, that the pointer coming in points to code that isn't already corrupted in the sense that it has several pointers and several threads. And when it goes out, how do you know that the code doesn't keep a copy and start mauling it? It's problems like that that's really difficult.

It's obvious that if you want complete guarantees, you must have all of your code following the same the rules that gives you that guarantee and that is feasible for fairly small isolated pieces of code it is not true for large code spaces especially the problem of passing information or to other pieces of code like written in old c plus plus or c or simpler scala some other language that can more a piece of code that can more some data and the larger the project and the older the project the more likely it is that there is external dependencies left and right you know with c libraries and legacy code and things that the compiler can't really you know see inside and prove no aliasing and things like that. But the other problem is that code doesn't stay new.

Say you write a nice little library in Rust, and for how long will it be only used from Rust? If it's forever, it's sort of in a fairly small world every new language think they're going to have all the code written in their language sooner or later but it's it's later or china's still around so it's cobalt and so what are the guarantees worse when it's called from a library that doesn't follow it, or when it calls a library that doesn't obey those rules? Then you have to trust it. You get more and more trust code in your system.

Your safety is always a caveat. Trusted codes really should be trusted. It's trustworthy. One of the problems is that a lot of code isn't. You probably will have to convince the compiler to trust it by marking it or something, which kind of negates the purpose of compiler static checks in the first place because you're overriding it. You're saying beyond this call assume everything is safe. Yeah, everything is safe. In other words,

hope it's trustworthy. Hope it doesn't violate the rules that you are trying to give to your users. We know that's not that. I mean, remember that Java bug last year? Which one? The logger one yeah it's only been trusted in places for for for 10 years it gave free access boy and we had a busy weekend and my security friends tells me that we were very very good to be able to do it in less than a month yeah so it's all the problem of the dialect and epochs all over again yeah

people who try to formalize evolutionary changes or years or decades, I think tend to be rather naive. If the problem was sufficiently simple, there are solutions for it. Like with epochs, if you have one epoch following another in a steady progression, each carefully designed to work with the previous

one. Things work. But that's not the way the world is. It's a way a small world is. In a larger world you have parallel evolution in different places and you have evolution of people who are in a hurry and says, I don't need to work with that old stuff, which is one of the motivations for that kind of thing. And the problem is that, well, now somebody else can't use your code because they depend on that old stuff. These are the problems we have seen again and again and again. Right. yes. We have so many papers to discuss still and unfortunately we've run out of time for today.

So I'll leave you with... I have some work I have to get done before two o'clock. So it's a good thing to get on. By the way, did I tell you I got on, I have to get done before two o'clock, so it's a good thing to get on. By the way, did I tell you I got on retired? Oh, what? No. I retired, went to Europe for a month. That lasted for two months. I was still in Europe, but they changed my status at Columbia,

so I am now a professor rather than a visiting professor. Oh, congratulations. Apparently, I've been a visiting professor for eight years, and the max is five or three, depending on who you ask. So they had to do something quickly. Congratulations, and sorry your retirement didn't last long. Well, it's fun. Let's do something quickly. Congratulations. And sorry, your retirement didn't last long.

Well, it's fun. I'd always want to keep my course. And now I've just moved the course to the fall so that I don't have to be in New York City for the winter. Fair enough. Wise as well. I don't like New York City in January, February, July and August. Those are not good months here. Right, I think that's it for today and I'll leave you with this tweet by Vector

of Bull, Colby Pike. C coroutines are like monads. Once you understand them, you must write a blog post that tries and fails to teach them to everyone else. That's a good one. If you look into Knuth, I think volume one, he has an apology for not giving a good example of coroutines. Right. So thank you very much for coming, for joining me today, and I'll talk to you soon. Bye. Thank you.

Thank you. Bye.