C++ Club - 172. Safety, Rust, Swift, WG21 papers, Contracts

Episode Date: July 21, 2024

With Bjarne Stroustrup, Gianluca Delfino, Frances Buontempo, Jody Hagins, Csaba Ráduly et al.Notes: https://cppclub.uk/meetings/2024/172/Video: https://youtu.be/dWz6s1oS2RY

Hello and welcome to C++ Club. This is meeting 172 and today is the 30th of May 2024. A bit of feedback. Robert wrote to me, You quote a prediction regarding regulation on software engineering and then ridicule it with a laughing track, a laughing track, like we were watching a sitcom. This was really undignified. Oh boy. Especially since I assessed the prediction to have some truth to it. It's already starting to happen. Customers start putting pressure on software developers to follow rules and fulfill regulatory requirements so they won't be liable if the software they bought causes damages." End quote.

Having worked as a consultant in many large firms over the years, I've seen things. Code written by contractors who don't give two shits about the quality of code they write. Current place being a rare exception. The entire defective and badly designed systems produced by outsourced programmers ruining people's lives like the UK post office defective Horizon system produced by Fujitsu, where software bugs were ignored and covered up. I'll put a link in the notes. Have a read. This has been happening for many years and it is still happening. And just wait for the onslaught of AI generated code containing subtle bugs. So forgive me if I'm not too optimistic here.

Now, one correction a Redditor wrote to me regarding my Swift remark, they say, it is straight there in Apple's official documentation and 2023 talks by Apple employees. Quote, Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics, giving Cocoa and Cocoa Touch developers the performance and power they demand." for them. I like Swift, it's a great language to work with. Right, I wanted to briefly go back to the previously

White House report on memory safety. I had some quotes gathered that we didn't have a chance to discuss, to see before. So in that document, there is this paragraph, quote, while formal methods have been studied for decades, the deployment remains limited. Further innovation in approaches to make formal methods widely accessible is vital to accelerate the broad adoption." And to that, one commenter says, well, gosh, I applied to US research programs with an interest in formal methods

and was rejected absolutely across the board. Good luck to you." So good in theory, but in practice might be complicated, yes. And also another Redditor said, this is in comment to Bjarne's response to the White House paper. This Redditor says, quote, I've been in the industry long enough to know that there's a significant number of devs that will refuse to adopt new language standards.

I'm 100% confident there are C++ devs still writing C++ 03 style code. Both before they simply haven't taken the time to know what's in C++ 11 and later, and because they have some mistrust and even irrational fears about enabling C++ 11 and later feature sets on their code bases. I dealt and still deal with these devs in the Java context all the time." I couldn't disagree with that. I've seen them too. They're a major problem. And you have to remember, as a statement he said that they don't have time to learn. Quite often the learning and introduction of new things are not encouraged in overrushed development shops. Yeah. There's even a movement called Orthodox C++, which promotes writing C++ or 3-style code without any C++11

and later features at all. The main proponent is a game developer, so that's C. Sounds a little bit like John Carmack, who suggests to use C++, but not basically using most of the features, just pointers, not even references. Oh, does he? I didn't know that about him. Why don't you just program in C? Well, you do get probably namespaces and other things.

I don't know if they use templates maybe not probably unlikely he's probably stuck on the style he used for doom was doom assembly oh no i will see you and uh and uh assembly and a lot of uh a lot of uh nifty tricks. Yeah, there's a video. Who did it? They ported Doom to C++ in the span of a single live stream. Was it Jason Turner? Yes, that was him. Yep. So yeah, that was cool. Yeah, and I recently had someone say to my, it was a code review and I was like you can use what was there a range for loop here instead of an old style loop and to that I got this reply that said something like I'm an old man I learned C++ long ago and I don't have time for new things. So let's just leave it at that or something like that. So yeah,

yeah. Yeah, you know, the Sean parents presentation, it was for seasoning, the famous, this is a rotate presentation. Oh, yeah, yeah, yeah. Yeah. So there's a variant of that when he tells an after story. So the example code that he simplified was in Chromium and it's still in there because the changes that he proposed to make a 50 line code into a three line code was rejected by the senior reviewer saying that nobody knows what rotate does oh my and it's still there i checked the chromium repo and it's still there

i'm i'm guessing as far as modern c++ goes, Chromium is a really bad example. Right. There have been several safety-related articles. One of them was Herb Sutter's post titled C++ Safety in context. It's pretty long and all the things that he says are very sensible, but I can't shake the feeling that in the background, in his mind, CppFront is hovering as a solution to all of this. At the end he says, quote, please don't be distracted by that CppFront uses an experimental alternate syntax for C++. That's because I'm additionally trying to see if we can

reach a second orthogonal goal to make the C++ language itself simpler and eliminate the need to teach 90% of the C++ guidance literature related to language complexity and quirks. This assays language safety improvements are orthogonal to that, however, and can be applied equally to today's C++ syntax." To be fair, his CppFront experiment uses it as a vehicle for trying out new things that can be applied to the standard C++. It's fine. However, this Redditor commented on this article,

quote, it's unfortunate that Mr. Sutter still throws C and C++ into one bucket, and then concludes that bounds checking is a problem that we have. This data really needs to be split into three categories. C, C++, as written by people that will never progress beyond C++98, and C++ as written by people that use modern tools to begin with. The first two groups should be considered as being outside the target audience for any kind of safety. Yeah, end quote.

A next article by Lucian Vradu Teodorescu is called Safety Revisited and it's an absolutely massive summary of pretty much everything, lots of links to presentations, papers and such. And he did a massive job with this post. Lots of quotes from various people involved in security and safety debate. Tons of paper links. Yeah, it's a very useful summary. It's a bit outdated, I think. Not too much outdated. So still useful,

but there's like a huge list of references at the end. You probably would have added this Schoenbaxter talk that was about C++. I guess, so this is, I'll ask if he wrote for overloading, was that back in February? So that was the edition before Herb brought out his safety paper and then Herb talked about that at accu as well so yeah lucian's was a month or two before some newer things it is a really useful paper for anyone who's listening i edit the overload magazine i remember reading through this and the discussion with the team about bits he'd missed and there's so much information in there but it's nice that he's pulled it together in one place like you said now a few months later of course

there's more things to add but yeah it's still a massively useful resource this article and yeah thanks for the overload magazine magazine is Magazine is great. I can also second that. Thank you. Freely available to anyone who heads over to IQ and wants to have a look. It's brilliant. There was another article by John Fenn titled

Looking for Pointers, the C++ Memory Safety Debate. An obligatory AI generated image. So a couple of quotes from it. Quote, the narrative for C++ as inherently unsafe oversimplifies the situation. The language has undergone substantial evolution with modern iterations emphasizing safer memory practices without compromising the language's core principles of efficiency and control. The journey towards making C++ a safer language is complex and fraught with challenges. However, the discussions and proposals led by Stroustrup and supported by the broader C++ community

suggest a forward path that respects the language's legacy while addressing the pressing needs of modern computing. By balancing the need for safety with the realities of existing infrastructure, C++ aims to continue its role as a powerful tool in the arsenal of contemporary software development, meeting the evolving demands of safety, efficiency, and interoperability. There was another quote from this article which went like this.

Right now, many of the articles about modern C++ and memory-safe C++ end up preaching to the choir. The advice doesn't reach all corners of industry, and many places in academia are stuck in their ways. If you go to small computer science programs at small schools you will frequently find people learning C++ as C++98 or C++03, so they see C++ as C with classes and templates, or Java without garbage collection." I think that quote was from Reddit's discussion on this. So moving towards, I guess, what these papers are calling safer languages, let's have a look at Rust briefly. An interesting effort financed by Google.

Google joined the Rust Foundation in 2021 and now they announced that Google has provided a grant of 11 million to the Rust Foundation to support efforts that will improve the ability of Rust code to interoperate with existing legacy C++ codebase. Hint, hint, Chromium. So I guess they are exploring the interop. Having lost all hope to convert their chrome codebase to modern C++, they decided let's just rewrite it in Rust, why not. Interop is good, by the way, I have nothing against it. And I'm sort of starting to look towards maybe learning Rust, shock and horror could be useful. And it seems like a nice language

if you don't pay attention to all the drama, which sometimes can be hard. But still, Google has this project, it's more or less internal, because it's tightly coupled with a build system. And it seems a bit neglected, maybe, judging by the failing build badge. It's called CRUBIT, C++ Rust Bidirectional Interop Tool. It's a bindings generator for C++ and Rust with the goal of integrating the C++ and Rust ecosystems. And they go, it's on GitHub and they have some examples, but I don't know how advanced it is or how much of what C++ allows is carried over to the Rust side. K-dub, the company behind Qt and CMake, posted a series of articles. This is a three-part article, Mixing C++ and Rust for fun and profit. It's pretty interesting. Lots of examples and lots

of considerations like name mangling, data layout and stuff. So presumably they are using it or trying to use it with some view of the future integration, maybe with Qt, who knows. But these articles are appearing more and more for bi-directional C++ support, and it's now very advanced. It's very well documented, and you can use C++ standard library from Swift pretty transparent. You can access Swift functionality from C++. So it's a pretty advanced interop solution. It's a new feature in Swift 5.9, which was released last summer, I think. It's still not complete, but they are making great progress, which is nice to see. And this is another confirmation of the fact that

you can't just abandon C++, especially if you are working with a language that is based for your operating system programming. And Doug Greger recently posted a series of articles, very detailed ones that help learn Swift, help C++ practitioners learn Swift. And it has details of both C++ and Swift that are really interesting. So I thought I'd mention that. Another article titled, Why Rust Isn't Killing C++ by Logan is a very good name. A quote. The internet likes to perpetuate the myth that C++ is a soon-to-be-dead language. I've seen many people say not to learn C++ because Rust can do basically everything C++ can do,

but is much easier to work with and almost guaranteed to be memory safe. This narrative is especially harmful for new developers who focus primarily on what languages they should gain experience in. This causes them to write off C++, which I think is a huge mistake, because it is actually one of the best languages for new developers to learn. End quote. Moving swiftly on, I was fascinated to discover this article by Rust Foundation team that said that in their report, 20% of Rust crates, which is like library distribution units, use unsafe keyword.

This is like 20% of all the publicly available Rust code. So it shows how difficult it is to sometimes use Rust without, how do I put it? From what I've seen, the Rust bounce checker sometimes can be very tricky to work with. And apparently some people just revert to using unsafe things instead of maybe jumping through hoops of the borrow checker. I think they could argue that the use of unsafe in some crates or 20% of the crates is somewhat unavoidable and confines that use to what should be very well-reviewed code. Then again, it also proves that there is a need of unsafe, somewhere

at least. Yeah. So this long, long article was posted by LogLog Games developer studio. And it's titled, Leaving Rust Game Dev After 3 Years and it's a very detailed account of their gripes with Rust but what... there was one quote that caught my attention which sounded familiar and not exactly limited to the context of Rust.

Quote, "'Learning Rust is an interesting experience, "'because while many things initially feel like "'this is a special problem only I am having, "'later one realizes that there's a few fundamental patterns "'that are universal, "'and that there's a few fundamental patterns that are universal, and that everyone learning has to rediscover and internalize in order to be productive. There is an overwhelming force in the Rust community that, when anyone mentions they're

having problems with Rust, the language, on a fundamental level, the answer is, you just don't get it yet. I promise, once you get good enough, things will make sense. So the problem you're having is only a problem because you haven't tried hard enough." You've noticed I'm quiet because basically I'm not very interested in language wars. But there's one thing I learned a long, long time ago when I thought that C++ programmers were so much smarter and so much nicer than other communities I knew. And I realized that a small coherent community is nicer, better informed than a large community. But when a community grows towards a large number, you get the law of large numbers, which is that the average is the industry average. And so it's fairly easy to do really, really well in a group of 10,000.

Try that with a group of a million and you get all of the problems that people are used to from large communities and languages, the large communities. It's unavoidable. We couldn't educate educators fast enough with C++ in some of the problems we see. And the same will happen to any language that actually starts getting a real scale. The enthusiasts are doing well. and when you get a million users you have a different set of problems.

Yes, yeah. Someone asked on Reddit, why all the hate for C++? And the first reply was, the vast majority of opinions that people espouse relate to their need to justify their decisions and should be of no interest to you. They are not trying to help you, they are trying to help themselves. Carry on. So finally, C++. We had a couple of mailings since the last time and I wanted to look at some of the papers. Right, this is P3166, static exception specifications. So is that the static exception effort only rewritten? I see throw specifiers, adding throw specifiers to function declarations. So this paper, quote, this paper has the following main goals. Eliminate the performance related reasons for not using exceptions in embedded and other

performance-critical code. And so on. Basically related to all the cripes people have with exceptions. So there was a paper with static exceptions Baker, I think, he's been involved in error handling and wasn't he the one who wrote a boost library for error handling without exceptions not too long ago? Anyway, it's interesting that I thought that static exceptions effort died out, but apparently not. Related to contracts, this paper by Gabby Dos Reis, P2900 may be minimal, but it is not viable. And this is related to the contract's minimum viable proposal. This is a pretty serious objection. He says, without adequate limitation on defined behavior in the evaluation of contract assertions microsoft considers the contract facility not viable in the contemporary environments where c++ is used

contracts facility that fails to adequately support efficient use with virtual functions and pointer to functions in is woefully is woefully inadequate and unready for prime use and inclusion in C++ 26 in particular. Microsoft recommends against the inclusion of P2900 in C++ 26. Microsoft recommends against this proposal without applications in the standard library, in particular in the algorithm section and field experience." So that was the pretty serious objection that other papers even quoted. Interestingly, without naming Microsoft or Gabi Dos Reis, I saw a quote that went like, one vendor expressed pretty serious objections to this. Like, as if Microsoft is a name not to be, something not to be named or something.

It's usually not a bright idea to disregard what Gabi says. Yes. So, some other papers from more recent mailing are P3274, a framework for profiles development by Bjarne Storstrup, which outlines, quote, this document outlines a structured framework for developing and implementing safety profiles in ISO standard C++. It addresses the industry's urgent need for improved safety and the challenges of standardization." End quote. So yeah, it's a

pretty thorough explanation of the motivation behind profiles. Verification explanation, what happens during verification. Like there are three groups that any analysis would put any analyzed code in. Verified safe for that particular definition of safe for that particular definition of safe, for that particular profile, verified unsafe, and verified possibly unsafe, which could mean that it's too complex to classify. That section, by the way, is trying to address the discussion about how about removing a

lot of the bugs, even though we can't get all of them? We have to aim for a perfect guarantee for a particular safety guarantee, or should we be happy by some approximation? The answer is not trivial. My answer is we have to aim for completeness, but we have to leave something open so that we can approximate that ideal. It might take a couple of months

or a couple of years to get to it, but we must undermine people's confidence in the general framework by having something that almost work i remember when type checking of function arguments were not complete as several people suggested at the time and my initial implementation says you only got it if you actually asked for it and people got absolutely paranoid because they learned that type bugs of that kind didn't exist in C++. And when they hit one, they were totally confused, totally dismayed. And after I've lived with that for a few months, it was then enforced,

even though it was the major incompatibility with C and basically made every C program not C++. But it was that important. I was willing to take a 100% hit on C compatibility for all C programs. Right. So then the document goes into annotations and the syntax is used the ISO standard attribute syntax like enclosed enclosed between double square brackets. Profiles, colon, colon, enable, parentheses, name of the profile. In another paper, I saw someone proposed using the at character for this, like add enable ranges for example, because add is like a valid character now and why not use it for something really big. More seriously, Ville Wutterleinen was suggesting that it was important to have a syntax that

made sure that if you fed something with profiles to a C++ 23 compiler, that it would not compile. And so the key thing is, would you be able to use profiles in programs that was actually written in an environment where C++ 17 was the corporate standard? And my answer to that is yes, we should. And So it's a real issue. Interesting. I see some familiar code from your Flats repository, the expect function template, which I must admit I made use of it very successfully. It's like, at the time, I thought it was like a contract check for people without contracts. You don't have contracts, or if contracts aren't what you can use, this is something that you can use in a particular project or organization.

I'm not sure how it will work as part of the standard. Right. And I see. So then the document goes into the actual profiles with descriptions and all kinds of details about each of them. The profiles discussed are type, arithmetic, concurrency, ranges, pointers, algorithms, initialization, casting, invalidation, RAII, union. Yeah, that's it. So this paper was meant to be about two pages. But Uber kept asking me for more details. And I hope by now it is not so large that people won't read it, which was what happened to some of my earlier papers because they were too long. But that it gives enough concrete stuff so that people can work on it.

This is a big project and we have to be able to work on parts of it, not the whole. And so I hope we get to the point where each profile or profile fragment can be worked on in isolation. And I'm trying to partition the problems so that we can have SIP worked. SL. So the next paper I wanted to look at was this p30100 and that is Undefined and erroneous behavior is a contract violation by Timur Dumler, Gaspi Rajman and Joshua Byrne. And this is an interesting thing that they say, quote, In this paper, we propose to specify and define the behavior that manifests at runtime to be a contract violation.

Our proposed framework replaces the concept of erroneous behavior and paves the way for a safer and more secure C++ standard. As we will show in this paper, the semantics provided by erroneous behavior are essentially a subset of the semantics that the contracts framework provides. We can therefore entirely subsume erroneous behavior into contract violation handling." End quote. Hmm. That's an interesting take, I thought. So does that make C++ safety and UB handling dependent on contracts?

Contracts was like an opt-in feature, right? Also, contracts have now been under discussion for maybe 10 years. Yeah, exactly. I doubt we'll get it in 26. And with this paper, we seem to get automatic implicit contracts everywhere, including in places where you might not want to use contracts. I'm not sure if I like this one, especially given exactly how contentious the contract feature is in the committee. We have to do something about on specified behavior, undefined behavior, but I see a certain urgency in doing something about it.

Right. So erroneous behavior was already accepted into the standard, as far as I can remember. And now this paper proposes to scrap that and instead say that it's all being handled by contracts. Another contract paper was written by Ville Vutilainen. It's P3338, an alternate proposal for naming contract semantics. It's probably at the first glance, it's not like super critical thing, you know, bike shedding naming stuff, but there's a but I think it was pointing out

that this mailing and the papers in it is about a week old and I did a quick count there's about 130 papers which I ought to understand

before the meeting in just under a month's time. It is hard to keep up on all of this and some of these papers seems to address fairly deep problems. sure whether the problems are deep just from looking at summaries and you can't see if the solutions would work without going deep into them. This is a lot of work. Yeah, yeah, totally. So, Wille says, quote, the current naming of contract semantics more or less follows the form something something the trueness of a predicate and we use the words ignore enforce observe and ostensibly quick enforce for the blank. This proposal suggests that we should use the form

a contract violation is treated as and that we use the words ignored, enforced, observed and erroneous. So that's one part of the paper. But now look at this, it's like an uno-reverse card for the previous paper. The more significant part, let me find where, oh yeah, the more significant part proposed here is that a contract with the same name, where contract violation causes instant termination without calling a violation handler, is simply treated as erroneous behavior, with a fallback defined behavior being called the violation handler. The previous paper says let's treat erroneous behavior as a contract violation and this one says no let's treat a contract violation like an erroneous behavior. It's a school of philosophy that says all deep problems

in philosophy comes down to understanding and misunderstanding of terminology right so yeah I'm curious Sergius I believe really curious how this will

pan out in the committee. There was an update to the contracts paper p29. The notable updates were an addition of the quick enforce evaluation. Quote, if a contract violation is identified at runtime, the observe semantic will invoke the contract violation handler. If the contract violation handler returns normally, program execution will continue from the point of evaluation of the contract assertion.

The enforce semantic will invoke the contract violation handler. If the contract violationion. The enforce semantic will invoke the contract violation handler. If the contract violation handler returns normally, the program is terminated in an implementation-defined fashion. And this is the new addition. The quick enforce semantic will not invoke the contract violation handler, but instead immediately terminate the program in an implementation defined. In the meantime, there was quite a big activity around contracts. For example, this paper by Peter Bindels, C++ contracts and... Basically this paper is not required for the MVP.

It defines behavior for a currently ill-formed construct. Basically the MVP says you can't have contracts on coroutines, and this paper says how you would be able to do that. The next one is contract testing support, which I thought was fairly sensible, except the word magic in the abstract. Quote, this proposal includes a few magic functions to perform only the pre or post conditions of a function given a set of function arguments. So I expect you would want to test your pre and post conditions somehow. And in the proposed example, you would have this magic function called check preconditions

with some parameters to a function and the function would be passed as a template parameter and the check would magically happen. So technically... I have an idea that something like contracts, you should be able to get the basics from reading one page and possibly two.

If something takes 50 pages to define, it probably becomes a source of errors in itself. Well, I think that ship has sailed. The MVP is itself how many pages? I don't know. 73. Yes. So, the next related paper... ah, here we go. Ville Vutilainen writes, ship contracts in a TS. Quote, this paper suggests that contracts should ship in a technical specification first, not in the C++ 26 international standard. The motivation for this is many fold.

We lack implementation experience, more importantly, field experience in the form of deployment and usage experience. WG21-wide design consensus on multiple points in the proposal, cohesion in coverage, increased safety, and so on. So yeah, he says, we have had language TESs before for concepts, modules, and coroutines,

and we got better features due to using a TS. And that would be also paying attention to what Gabby Dos Reis says in his paper. But there's another paper titled, Do Not Ship Contracts as a TS by Timo Dummler and John Spicer. And they naturally are trying to justify shipping contracts as an international standard instead of tiers. Because according to them contracts address an important part of the C++ safety problem. When you read this justification, it sounds almost like if we have contracts, we'll have safe C++, which is not really the case, I think. It's not some sort of automagical solution. This is where you must use your love track.

Gotcha. Then they say wire contracts TS does not help. They say a TS would not be an efficient use of time and resources because the TS process is slow and bureaucratic. To be fair, they list some outstanding issues with the contracts MVP. And it's quite a lot, actually. And given how the committee is progressing with contracts, it doesn't fill one with lots of confidence. Their position is that targeting a contract's TS would be a mistake. Now, there's another paper by Joshua Byrne, Steve Downey and others, including John Lakers,

P2900 is superior to a contract's TS. It has been proposed that the contracts should ship as a TS rather than as part of the international standard. While some technical and political concerns with P2900 need to be considered, ATS is a viable solution when only it has the potential of answering those questions. Our position is that none of the current issues fit into this category, and we strongly believe that work on evolving the contract's proposal should continue until it has consensus to be adopted into the international standard, preferably in the C++26 timeframe. But was that it? Oh no. Next one. P4000. 2ts or not 2ts? That is the question. By Howard Hinnant, Roger Oh, Janus Torstrup,

David van der Woerde, and Michael Wong. AK, the direction group. AK, sorry, sorry, didn't hear that. The direction group. Oh, the direction group. Yeah. So basically a bunch of people that know nothing about C++. As some- Try that line. So we, the direction group, recommend answer the key question. What are we hoping to learn through ATS must be clearly specified. What are the exit criteria of the TS2-EIS

must be clearly specified. Use TSS for library components. Don't use TSS for a language feature, unless the feature is a mostly self-contained unit. Don't use a TS simply to delay. It doesn't simplify later decision making. Have concrete and articulated criteria for completion. So far, no TS is winning. Let's see the results. C++26 needs contract checking. Elchig, Matthias Kraus, Ryan McDougall and Pez Zarish. Well, this one was pretty dramatic, I thought.

Abstract, quote, contract checking is the single most important way to address C++ memory safety from C++ in a simple, easy and backwards compatible way. The opportunity cost of not having contract checking in C++ 26 is too high." End quote. Well, now I'm convinced. They do mention go into safety then basically they are C++26 without construct checking might as well not ship at all I don't think

anybody would disagree with the fact that contracts would be a good thing. The problem is that there's a lot of details and that some of the definitions of contracts we've come up with, actually all of the ones we've come up with,

have gotten strong opposition from some people, including me in some cases. Furthermore, there are things that you can't really do with contracts such as i want a contract that this pointer doesn't dangle or i want a contract that this file doesn't disappear after i have verified it is there, before I use it. These are beyond simple static or runtime checks. You need something further than contracts. I mean I'm particularly interested in dangling pointers and eliminating pattern resource leaks. We seem to have run out of time, but if you have 10 minutes, I would like to cover a little bit more, if that's okay. I just want to finish up with the paper. We are now switching to papers related to

this paper P1306 Expansion Statements by Andrew Sutton, Sam Gudryk, David van de Voorde, and Dan Katz. Quote, this paper proposes a new kind of statement that enables the compile time repetition of a statement for each element of a tuple, array, class, range, or braced limited list of examples. We seem to have had that previously in the previous reflection proposals, like code fragments or something. And this basic usage example

demonstrates how you can output all elements of a tuple currently using the HANA library with HANA for each, and then how you can do that with a feature described by this proposal. And instead of HANA for each with tuple body of the loop you would use a construct called template4. It looks like a range four, but the container in this case is not a container but a tuple. And you iterate through all the elements of a tuple like in a normal loop. I haven't seen this paper. It's recent. But this follows up on a previous paper, I think they'll call it Expansions, or something like that. And it was rather well received. The commenters on Reddit especially are very excited by all these papers that demonstrate all the things that we can have if we have reflection, which is really nice. Like this one. Code injection with talking sequences

by Andrei Alexandrescu, Barry Revzin, and David van der Woerde. Wonderwood. They explore variants of syntax that would allow you to inject piece code fragments into your code, like meta... not the meta programming that we know, but some kind of other higher level metaprogramming using reflection. I don't even know what to call it. But it does use the std metaprogramming namespace. Actually, imagine how difficult it would be to explain to someone, once we have reflection, that template meta programming is not always related to the std meta namespace that actually is related to reflection. So we now have two kinds of meta things in C++. So this one was interesting. And another one is generative extensions for reflection by Andrei Alexandrescu, who by

the way now works at Nvidia. Go figure. Barry Revzin, Bryce Lilbeck, and Michael Garland. And this one proposes constructs like inject function, declare function, set name, set qualified name, and a bunch of other features based on reflection. I think in one of the papers, maybe even this one. Yeah, somewhere in this paper, I don't know where, they sort of imply that you can inject properties into a class with the appropriate getters and setters and the underlying member variable automatically generated. And that reminded me about the metaclasses proposal

that is currently was marked. It has been marked as abandoned just recently but um it may live in another form i mean it does look like that right i remember the talk originally from accu may have been 2017 where saturn presented it and at the beginning you know i think it was a bit shocking for the community to see something like that but maybe after the time we had to digest it. Have you noticed that lots of proposals these days seems to grow into whole programming languages in their own right? Yeah, that could be a problem. Oh, by the way, there was a discussion on Reddit regarding the... Yeah, code injection, this is really, really cool.

Expansion statements. Someone said... Oh yeah, this one, a quote from Reddit. I still feel like my opinion has never changed on C++, which is that C++ really should stop trying to ship anything until epochs are in place. End quote. Talk about oversimplification.

You know, it's really easy to have a cool idea. Making it real, making it integrated, handling feature interaction problems is hard. Yeah. It was shown before that epochs are, I think you, Bjarne, said that they are impossible to implement and would result in C++ dialects. Yes. But, on the other hand, like you said now, if every paper evolves into a programming language, we risk having done by the way of some papers. Yeah, but not every proposal gets into the language. This is one thing that Reddit and to understand. Most languages die, most language proposals die. It's not real just because somebody has had an idea.

So pattern matching got mentioned sadly very briefly, but this paper titled A Unified Syntax for Pattern Matching and Contracts When Introducing a New Name by Ran Regev. The author says that we have two ways of introducing a new name. In pattern matching, we have within the match statement let x arrow and then something that defines it, some other piece of code, and the arrow is equals greater. And in contracts, in pre and conditions, we use ret colon and then something to do with ret, like a condition. So there are two ways of introducing a new name.

And the author of this paper proposes to use let arrow. Walter Brown wouldn't agree with this. Exactly what I thought, yeah. Isn't arrow used for the C++... what's it called? Implies? Implication, yeah. Implication for C++. And also let is a... There's a separate proposal by introducing an implication operator.

Just to give a third way of using that token combination. Would that be a separate symbol or something or a combination of symbols? Walter Brown's paper or an implication. Right. So yeah, let seems like not just part of the introducer, but something that has a meaning. It can be a let or it can be something else. And using a combination of let and the arrow seems like maybe a bit of an overhead. But yeah, it's an interesting idea, maybe, from the point of unifying the syntax. So who knows.

At the very least, it reminded people about the pattern matching proposal, which is good. And this is a very curious paper by Hanna Dusikova, p3125,inter Tagging. This paper proposes a library-based design with magical functions to store and retrieve information into bits of pointers which are not significant to the pointer's address, and to inform developers about how many such bits are available." End quote. That sounds a bit scary.

She says, pointer tagging is not allowed in standard C++ as manipulating pointer bits is UB. Because of this limitation, some advanced data structures are not implementable or sub-optimally implementable. This technique is an existing practice, is widely used in the field, and standardizing it would lower the bar for its safe usage among C++ users. And there's existing usage on different platforms for memory tagging extensions and some other LLVM codebase uses it. yeah there are precedents but still it's um one of the riskier features i would say that prob that's probably why she would want to see it standardized make it safer to to play with this kind of knives uh i mean i i would assume this is used in embedded a lot. Probably. I don't see this, luckily. And the final paper for today is this one. Reserve identifiers preceded by ampersand for non-ignorable annotation tokens by Brian. So C++23 added the ampersand character to the basic source character set.

And this paper says, outlines cases where that could be used. Did you say ampersand or at? At, sorry, not ampersand, sorry. It's an add symbol. Thanks for noticing that I zoned out. So yeah, one of the examples is contract annotations, where you could say add assert or add pre or add post. Trivial relocatability, like an almost an attribute, but not the normal C++ attribute that we have. Indeed, because those are ignorable, right? Yeah. And this one is profile annotations that I mentioned. One member suggested the syntax atEnableRanges as an example of a non-ignorable syntax for enabling the ranges profile.

It's a nice symbol. It'd be a shame to use it for just variable names, right? Just be glad you don't have to have a well-reasoned opinion on everything here in about four weeks' time. Right, so that's the papers. I think we'll end here, and I'll leave you with something funny. This is a picture. Dea Obasanjo and Ivor Hewitt also suggested it to me. There's a comic panel, you know, the meme with a dinosaur talking to the audience of dinosaurs, and the dinosaur says, what's the difference between a light bulb and a programmer? And then second panel, a light bulb stops working when it burns out.

And the dinosaur cries at the end. This is us. Oh, this one I wanted to show you. Jessica writes on Mastodon, I think programming is like running a dishwasher. It always takes longer than you think, and some stuff is never as clean as you expected it to be. That's it. Thank you very much for joining, and I'll see you next time. Bye.

Thank you. Bye.