C++ Club - 170. WG21 Feb '24 Mailing, C++ Successors, Reflection, Pattern Matching

Episode Date: March 7, 2024

An office meeting pretending to be a podcast. With Gianluca Delfino, Frances Buontempo, Dmitry Kuzminov, Jody Hagins et al.Notes: https://cppclub.uk/meetings/2024/170/Video: https://youtu.be/vMIvCyW-Qnc

Welcome to the C++ Club, an office meeting pretending to be a podcast. This is meeting 170, and today is the 22nd of February 2024. About the C++ successor languages, I heard this from a colleague, thanks Chris. So he said it about Scala in an unrelated discussion and the quote goes like this, more or less. Scala was initially positioned as a better Java when Java evolution stagnated. It had lots of syntactic sugar and more features including functional programming. Some were very enthusiastic about this and took a risk of adopting Scala. Now they are finding themselves in a pickle due to slow language evolution and death of

expertise. In the meantime, Java gained many of Scala features and is more popular than ever." This does remind me of how C++ successor languages are being positioned now. And to quote one of my favorite podcasters Joe Kasabian, time is a flat circle, everything repeats. Speaking of successor languages, there was a reddit post. What's the status on C++ 2.0 compilers like Circle, Carbon, Cpp2, etc? Will Circle ever go open source? And one of the questions that the redditor posted was, why is Circle not open source? I don't want to get my hopes up for

a language that will end up being a pain in the ass to use commercially. Yeah, one of the replies, the first reply actually, says, Carbon is destined for killedbygoogle.com sooner or later. There's no way in the world I'd be rewriting my decently large codebase in anything they could pull the rug out from without warning. They seem to keep working on Carbon. There's some progress and they posted some, I think there were some blog posts about it. So at least the effort continues. I've seen a recent video with Chandler Carruth stating how much carbon was an experiment and they don't know if he's going to succeed and it's going to take years. And I think, you know, I think we're still far from having an answer there, as far as I understand.

So they seem to be managing people's expectations. You know, I understand that because, you know, there's a lot of a lot of people that would like to jump on that bandwagon. And Herb Sater is doing the same thing withPP-2. He also emphasizes constantly that it's an experiment and he doesn't know where it will end up, which is fair enough. But despite that, many people seem to be eager, like you said, to jump on the bandwagon.

Someone posted on the same thread, quote, The COVID-19 lockdown period was the great era of C++ success experimentation. Lockdown is over, and we are all ordered to go back to work. Yeah. But what's most interesting in this particular thread to me was a discussion on Circle. Sean Baxter, the author of Circle, replied to the original question about Circle not being open source. Quote, Compilers need paid people to work on them, open source or not. Nobody is paying me to work on Circle, so I'm pretty certain nobody will pay anyone else to work on it either. I'm burning

savings every day that goes by, and I need to prioritize software development rather than all the other stuff that an open-source effort requires and which won't advance the project technically at all. The status of Circle is that I'm very deep in implementing memory safety. You all are free to go implement borrow checking in a in an open source project like GCC or Clang, please do." I find this strange. I can understand his position as the owner of the project, but I don't get it. What's his play here i mean he must have to say it's must realize that the path to adoption of circle is blocked by it not being open source could be that this is his uh his child in a way and he wants to understandably protect it in a way that may be in a sense a

detriment to the future of the project but maybe again that's uh i mean it's prerogative to to keep things as as they are as you know you did yeah yeah i mean it, it could be that his purpose is not to have a real success story in the end. Maybe he just wants to have fun playing around and, you know, more power to him. Or maybe wrong entirely. Maybe he's been playing 3D chess and maybe he could also be argued that at this point in development, wherever that is, he feels like he can make progress by himself faster than he could coordinate some

sort of open source concerted effort. I think your first idea is probably what's going on. He wants to be in control of his baby, so to speak, and doesn't want anyone else to set its path forward. But still, I mean, he said he's burning savings, so he must have some sort of an exit plan of sorts. Is he hoping that someone will buy him out? I don't know.

It's weird, especially given that it doesn't support Windows, which is probably a major part of people's workflow for C++. So yeah. That'd be interesting to know, though. I mean, certainly we're grateful to Schomb Baxter trying to pave the way to actually test this kind of new ideas. And and probably a lot of those are being tested thanks to his effort. So that's all good. I mean, we're getting we're getting old for free. So it's certainly we're not complaining.

It'd be interesting to know if he does have a plan for the future and what's his mind. If anybody knows. Yeah. I suspect he's the only one who knows, but yeah. Okay. A mailing has dropped. A February committee mailing. Which is labeled Pre-Tokyo.

I'm not sure when the next meeting in Tokyo is scheduled for. Probably... It's mid-March. Mid-March, okay. And as promised, there's quite a few papers. Like, a lot. You can see there's plenty of old ones with new versions and a ton of completely new ones at a version zero so it's really really interesting there's

obviously a red reddit thread which starts with more reflection baby in capital letters. Yes, that's always good to see progress in that. Let's start with the reflection paper. To start on that, I listened to the CPP cast episode on reflection with David van der Woorde, which was really interesting. It's not a long episode and the actual talk on reflection takes about half an hour or so, so I should all go and listen to it for interesting details on how this all started and how the proposals developed. Like, for example, the initial proposal was for type-based reflection, whereas David van de Vode's new proposal is value-based reflection, because, as he said, while type-based metaprogramming is really powerful, it's really difficult to debug,

and it doesn't look like a normal C++ programming. And so in order to be able to use standard constructs like for loops and if constexpr statements, they proposed that reflection would be value-based and that's what they're going forward with. So yeah, this is the episode. Some interesting tidbits from it tangentially related to reflection were when David talked about his work at EDG which is an abbreviation for Edison Design Group. I didn't know that. And the EDG compiler is widely used in embedded area and also as a a front end, as something that powers Visual Studio IntelliSense.

So it's like a whole additional compiler running all the time when you're working with Visual Studio. And the interesting part from my previous experience, I think it's now better at following the actual compiler, the MSVC compiler. But in the olden days, it sometimes happened so that IntelliSense would flag different errors or wouldn't flag errors that the compiler later did, which was a bit confusing. It's quite good now. And one of the features of the GD compiler that David was talking about was that because it's used as a front-end for IDEs and such, it can impersonate other compiler front-ends to the point of all the

bugs that they have in particular versions. So you can say, you can configure it to, for example, do the same thing as GCC version 7, and it would reproduce all the diagnostics and all the bugs of that particular version. And I thought that was very cool and also terrible if you are an EDG developer. Yeah, it definitely is. Imagine how difficult it is to try and match your product to some third-party product in the past. I don't even want to think about it, but it could be useful for many teams that have to

support multi-port compilers, and maybe they do have a CI with those compilers at the end of the day, but while they are actually writing the code, they could already be getting some feedback. Yeah. It's like Windows backwards compatibility, they always try to mimic their old bugs to keep some old software working, and that's even worse. So back to the reflection bit of the podcast. They talked about syntactic choices. If you remember the

paper, they... let me find some of the examples... oh yeah, this weird syntax with square brackets and columns as delimiters, and also the caret. David said that all the good delimiters were taken and when they thought about using the previously planned keywords like reflexper and unreflexper they thought they were like really cumbersome and unwieldy. They looked heavy. Too much syntax, basically. So they went with these delimiters, especially given the potential future extensions of reflection, which used square brackets, not with colons, but with some other delimiter for an additional meaning. So that's a possibility to extend the syntax later. Let me get this right. So this syntax is supposed to be the better alternative than using types because it's more like what we write in C++ now. Is that right?

So I think this syntax works with the whole reflection machinery. It works with the metatypes, so to speak, that you can operate on using reflection features. This syntax is called splicer. Splicers work together with the carrot, which is sort of a lift operator. It lifts a normal type into the realm of metatypes, or metatypes into the realm of reflection. And then you can operate on it using reflection features. And then by using splices you can turn it back or... what's the term? Materialize? I'm not sure. Back into the C++ type system. So like in this example, if you use both, it's a noop. For example, a splicer of a lifted type is the type. Like here, for example. Interesting.

Yeah, I don't know, Jordi, if that answers your question. I think the two things might be orthogonal. After reading this proposal and listening to David, my impression is that it'll be some time before I feel comfortable with the syntax and the notions of meta-meta programming. It's a whole new realm, and it's very interesting, and the possibilities are really mind-blowing. Like always, one of the examples of any reflection library or feature or macro is always stringification of enum cases. And here it's just a minor thing that you can do, apart

from all the other mind-blowingly cool things that you can do with reflection. The cool thing is that you can operate on types as if they were normal objects, normal values. And that's, I guess, the advantage of this variant of reflection being value-based. Look how easy it is to produce an array of types. If you recall various libraries like HANA, for example, it's quite a, I mean, the usage is not too bad. But when you go and see the implementation, it's just scary to look at.

Whereas here, it looks like a normal C++ code, which I guess is the goal. Yeah, I actually think this right here answers my question before, because this kind of ties the syntax in with the idea of the objects, because that right there reads very well to me. Yeah. So this podcast, this is the discussion about it. And the first comment starts with the words that are like a trigger to me. Why can't we simply... A question like this doesn't bode well usually.

Yeah, there's always the why can't we simply... Yeah, why can't we simply have three columns instead of all this terrible syntax. But in general, everyone is very excited about having Reflection. From what I can gather, it's progressing really well, and there's really hope of getting it into the next C++, which is 26. Really glad. Imagine the possibilities. I'm still amazed. Yeah. Yeah. That would be awesome. So this topic actually is quite dear to me. What do you guys use right now for reflection? The Magic Enum library, I think. But that's just for enums only. We don't use any other libraries specifically for general purpose reflection.

And now, a surprise. Pattern matching! Yay! A new version! At last! Is this also proposed for 26 but more likely 29 but that was based on the lack of progress that people observed on the mailing lists and the lack of paper updates. But now that we have this paper, maybe, maybe there's hope if the committee chooses to discuss it. So the notable change in this paper... if you remember previously we had an inspect keyword that initiated the pattern matching machinery. And now it's match, which I think sounds better because it has equivalents in other languages, notably Scala.

I don't know what- We are also taken away from Scala in the end. Yeah, yeah, exactly. That's a good point. Yeah. Does anyone know what Rust uses? I'm not sure. But if it's Match, it's... yeah, even more natural. Get all the good bits from other languages. And not only that, the match is an expression, which also gives you possibilities like, you know, assignment of the result of pattern matching. There are quite a few examples in this paper, and they look pretty. So the Tony tables for this proposal list versions of code in the current standard C++ 23. The second version is P1371, which uses Inspect. And there was another one, I think. Slightly different Inspect flavor.

I can only see the difference in the variable name or sudo name that we don't care about, two underscores instead of one. And then this paper using the matched keyword. And it looks similar to what was in the other papers using the inspect keyword. But now, instead of writing inspect parentheses S, using the inspect keyword. But now, instead of writing inspect parentheses S, you would write S match,

and then the curly braces that start the matching block. You can look through the examples and see what you can match, like you can match tuples. Oh yes, and another thing new in this paper is the keyword let. Hi Swift! Which introduces a variable in the matching statement, which receives the matched value. So it's doing something like auto? Yeah, I suppose. I'm not sure why let was chosen instead of maybe not.

I don't know. I'm sure that there is some pattern that they are lifting from some other language, like you said, either Rust or Scala. In Swift, let means constant, as opposed to var. So maybe they imply that whatever is here, whatever is introduced here is a constant.

I have to read the paper. That raises the question whether Y is a reference or value. Yeah, it's like, you're right. It's like structured bindings. It's something completely special. Maybe there's a case here as well. Maybe in the paper they specify. But yeah, this is going to raise also some questions in general, just for this lit. Yeah, yeah. But in any case, a progress. I'm very hopeful. Reflection

and pattern matching would be my wish, my secret wish for 26. Not a secret. My publicly known wish for 26. Not a secret. My publicly known wish for 26.

Each one of them by themselves is a game changer, right? Yeah, correct. Yeah. So any of these papers on matching, do they dictate what type of performance guarantee there should be in the matching?

Because some of these are complex structures. They're not necessarily things that are easy to just, you know. I'm not sure. I think it's too early to talk about. I think they might have thought that it's too early to talk about performance, as I don't think there is even an implementation of this particular paper. But I'm sure they'll say something like, because it's compiler-specific, there are no guarantees. But at least it should be no slower than the existing constructs,

like if or switch, or whatever applicable. But yeah, that's a good point. It has to be efficient. How does this proposal align with reflection that we discussed 10 minutes ago? So there should be really inconsistency, and so far I don't see this consistency in those two papers. maybe this proposal could be built on the reflection proposal, because matching can be done on things like types and it can be polymorphic. So like here, matching polymorphic types. So maybe reflection will be a vehicle for this proposal. But at this stage, I can only guess. That would be like lifting this into this meta type, more conceptual space. And so we'll be like meta matching. Maybe instead of

values, we could be matching concepts even maybe they will work together. Maybe they are a perfect match for each other. Because fun unintended. And so far, that doesn't look like they communicated to each other. So there are no three columns like in the previous proposal. This one looks more user-friendly. Well, you know, the usual situation of the committee members not talking to each other, I guess. But maybe as they start discussing

it they will come to some common platform and I quite like the idea of these two proposals working together because they do look like a normal C++ programming with some extensions obviously and yeah they might be perfect for augmenting each other wouldn't that be very happy for the minimum viable products taken from each to just get merged you know maybe yeah less less but you. Oh, the thing will get in 29. Sounds so far away though, 29. Yeah, it does, doesn't it? Depressingly far away, given all the shit that's happening in the world.

Anyway, back to the papers. Steadoptional of reference. So, to remind everyone, this is paper by Steve Downey and Peter Somerlad. They say, quote, We propose to fix a hole intentionally left in stdoptional, an optional over a reference such that the post condition on assignment is independent of the engaged state, always producing a rebound reference, and assigning a u to a t is disallowed by static assert if a u cannot be bound to a t reference."

So this seems to be progressing. I remember there was a deliberate omission of stdoptional because people couldn't agree what happens on assignment, and now they decided that it's always a rebound reference, not assignment through it to the referenced thing. I mean, if you have a paper that states you don't have a choice, then yeah, maybe it'll succeed this time. It would enable some nice things like chaining function calls and such. Good thing it's progressing. Because we can then use the then. I've never used this dot then

yet but yeah that would unlock that for these kind of cases as well. Yeah, yeah, if a function returns a reference there's no way you can chain the calls at the moment if you want to make it optional and do the optional chaining. So yeah, that would be a patch for this whole. Right, the next paper is Principled Design for WG21. This is a paper by John Lakers and others from Bloomberg and it's 65 pages. The table of contents takes two pages. And the abstract says, quote, the paper presents a formal, systematic, individual and group-friendly design selection and or refinement methodology called principled design. We offer several examples of using this principle design process to evaluate proposed solutions using relevant, characterized,

and ordered principles that represent design criteria and to compare each criterion to each solution. By scoring each solution against each principle in turn, we can quickly elucidate which solutions are non-viable, ultimately guiding us to consensus and an optimal resolution." This paper tries to formalize the process of like five-side vote, and formalizing it so that it's easier. I started reading it and it starts with an example, a demo so to speak.

The example is choosing a venue for an office event. As a light-hearted introductory example, imagine a team of eight people working at a small company and tasked with recommending the venue for the company's end-of-year employee outing. Vic, the team leader, writes the task on the whiteboard. And he says he writes problem statement, business justification, measures of success, and so on and so forth. And he receives several suggestions. He lists reasons, concerns for each of those. And then the main process starts and the process is transforming

reasons into principles. And then the hypothetical Vick starts assigning various properties, identifiers to choices. How busy we are, how friendly is the restaurant for talk, and such. Cost considerations, timings, accessibility, and so on. And so this example goes on and on and on and on. Now I'm very involved in VIX history. And on. And choosing the optimal solution involves ranking all those properties for each of the venues

and choosing the objectively best choice. So there is a happy ending, at least. Well, for this example, yes. At this point, I had a rough idea what the paper was about, and my takeaways from this paper is that, first of all, it's so meta. I mean, I'm sure it's very formal and it defines everything that can be defined for the WG21 process. And if everyone in WG21 follows this process, it will be perfect. Basically, what this paper does is it adds a level of indirection

on top of the existing WG21 process. There should be an app for that. No, seriously, there's so much meta-activity involved that someone should write an app for that. You're in danger of hitting good with incompleteness theorems and similar here if somebody were to put forward a contradictory proposal the brief glance looks like you're trying to weight things or agree which one's more important than something else so that still

involves talking to one another so even if you can come out of a formula of what to do after everyone's agreed, you're not dealing with the disagreement part. Though again, that's just a skim read over your shoulder here and now. Weird. Yeah. The committee doesn't have much time as it is now. and to load it with an additional process. I'll have to read this carefully, because I agree that the current situation is not ideal. And you know, maybe maybe they know, if they spend so much time writing this 65 pages down, I think they may have been thinking about it very hard.

So I think I will have to dig through, you know, and I'll let you know what happens to Vic at the end of the paper. Well, one thing for sure, Vic never gets to choose another team outing ever again. Vic resigns and quit Rages. So this paper has a set of examples or example applications of this paper to existing proposals, which might be interesting. But yeah, papers like this often rely on people following the process exactly, and that rarely happens. We'll see what the Tokyo discussion brings on this one. Another paper I saw was this, vocabulary types for composite class design. and it's a previous, it's a new version of the existing paper that talked about polymorphic types, polymorphic value types, and they renamed them now to

indirect and polymorphic, which looks better and I think this feature could be useful. They say, quote, the standard library has no vocabulary type for a dynamically allocated object with value semantics. So they provide it. I'm happy to see that Sean Parent is still actively working at getting C++ better. And he's not just focused on his new... It's not called Val anymore. It has a new name. Yeah, yeah. David van der Voorde talked about it

in the podcast that I listened to. But yeah, I forgot what it's called now. This is a paper called Quantities and Units Library, and it joins together previous libraries, because apparently they underestimated the amount of stuff that is needed for a feature like this to be introduced into the statement library. But yeah, I'm glad this is also progressing because standard units would be a good thing.

Yeah, yeah. But it's still early stages. They say this paper is incomplete and many chapters are still missing. It's published to gather early feedback. Fair enough, yeah. I'm hoping this won early feedback. Fair enough. Yeah. I'm hoping this won't be too controversial though.

Yeah. Yeah. There's plenty of previous art on this. So yeah, why not? Well, the good thing about it is that when you look at the list of authors on this paper, most of them have written their own units libraries and they all have experience with this within relative domain. Yeah, good point. So good thing they come together for this. This stdbasic-fixed-string by Mateusz Pusch, one of the authors of the previous paper, is like a yak shaving paper for that one. He says this paper proposes standardizing a string type that could be used at compile

time as a non-type template parameter. And also he says, this type is intended to serve as an essential building block and be exposed as part of the public interface of quantities and units library. If this comes into the standard, it'll make the subsequent units library easier and smaller, which is what the Mikado method is about, as I learned recently. Good stuff. What is the Mikado method? There's a whole book about it,

but in short, as I understand it, it's, for example, you have a long running branch with a new feature and some of the parts of that are backwards compatible. So you want to minimize the final change by extracting smaller features and committing them early so that you split the work into parts that can be implemented by themselves and so you make the final result more isolated and easier to apply. That's my take on it. Or maybe that's one application of the Mikado method. Sounds good. This paper called Allowing Exception Throwing in Constant Evaluation

by Hanna Dusikova also sounds like a patch. We have more and more stuff added to the constexpr set. More and more stuff can be used in constant evaluated mode and can't throw an exception. And this absence, she says, forces library authors to use more intrusive error reporting mechanisms. And if we kept the mechanism the same, it doesn't matter that we can't actually

throw exceptions at compile time, but at least we could keep the code the same. So why not? The next one is called std execution introduction And it's quite a short paper which is significant because the Stat Execution paper is quite big and maybe hard to understand. And so this paper is like a short and concise intro. It lists various values that were considered by the authors of PIN 2300 and quickly goes through the asynchronous model and explains what is structured concurrency and introduces to the actual framework with the basic building blocks like senders, receivers, operation state, and scheduler. I think it's very nice that they wrote this paper, because to go and start reading the

actual 2300 can be a little intimidating. And there's also a companion paper, a plan for state execution for C++ 26. Quote, in this paper, we aim to identify and prioritize the critical work items that need to be worked on in the C++ 26 cycle. So basically it's a minimum viable product for senders receivers, which is also good. And another companion paper by Bryce Lelbock, C++ asynchronous parallel algorithms, which builds on to senders receivers and enables

using algorithms on top of that, which is completely natural and more power to them. Another feature that is going to be a game changer, senders receivers and whatever it is we get in with the executors. I think we definitely are getting them in 26. This is going to be a big release. Yeah. You're going to have to buy all new books. If there are new books. Or write them. Yeah, sure. Now, a set of papers is about introducing a graph library in the standard. There are several papers on that. I am only going to mention

that it's happening. I mean, the papers are happening, not the actual feature in 26, but still could be very useful. This paper, Refining Contract Violation Enumerations by Joshua Byrne, it clarifies what kind of information a contract violation handler receives when invoked as a result of contract violation. I think we discussed contract violation handlers previously. And from reading this paper, I sort of understand that there can only be one contract violation handler in a program, but it will receive a bunch of information about a particular violation, including source, location, function name, what kind of contract, contract assertion,

was it like pre-condition, post-condition or assertion and so on. So yeah, this is all progressing. And finally, printing blank linesd println, which prints string followed by newline. And apparently you can't just call println without parameters. You have to pass it an empty string if you want to just print a newline. And this paper fixes that hooray you know i didn't even know about printer len but yeah this is nice it's a good thing to understand yeah does it flush the buffer oh good question i have no idea it's just syntactic sugar from the front of his glance.

Yeah. Right. I think we're out of time. And I still have a lot of stuff to talk about. But, yeah. Next time. I'll leave you with this Mastodon quote by

a bad idea. Quote. A significant part of my job is telling the customer that their code contains undefined behavior that could explode in their faces on next compiler upgrade. To which the response invariably is that they are still using the exact same build of GCC as the day the company was founded in 2007. And they will bury that exact binary of GCC with them in their grave. So that's it for today. Thank you very much for coming and I'll talk to you soon. Bye.

Cheers. Bye.