C++ Club - 169. WG21 Mailings, Contracts, C++ Ecosystem

Episode Date: February 11, 2024

With Gianluca Delfino, Frances Buontempo, Vladimír Arnošt, Mohamad ElKaissi, Mikhail Zborovski and others.Video: https://youtu.be/-G7HU_zOD6UNotes: https://cppclub.uk/meetings/2024/169/

Right. Welcome to the club. This is meeting 169 and today is the 25th of January 2024. And we'll start with a new conference. There is a new online-only C++ conference called online UK 2024. It runs from the 29th of February to the 2nd of March, with some workshops on the 28th. The sessions will be live-streamed, workshops as well. Tickets are available now, lots of familiar faces and speakers. And they've just published their schedule, which includes talks by Peter Summerlad, Mateusz Pusch, Andreas Fertig and Rainer Grimm. So it looks like it's going to be a very interesting conference and um i hope they publish their videos at some point and this is free of any fees no no it's paid you can buy tickets now there's a link to buy a ticket. How much is it? General admission costs 100 quid plus VAT. Workshops are a bit

more expensive, 480 VAT included. And you can pick and choose whichever workshops you want to attend and buy tickets for so yeah a new entry it's gonna throw in i've been chatting to phil nash and he's asked me if i'd like to speak as well so i've been busy trying to have a think about ai in particular and whether that's going to replace programmers but i need a bit of an update for my previous offerings, I think. I need to chat about chat GPT just a little, sort of throw that in. I'd watch that. Cool. Right.

The next item is a bit of a sad one you know Reiner Grimm unfortunately he has ALS amyotrophic lateral sclerosis that's neurodegenerative disease and

he's doing a money raising campaign for ALS research. Incidentally, that's the disease that Stephen Hawking had. Judging from his posts, he is already in quite an advanced stage. So there are some difficulties that he has with the daily life, which is very sad. So yeah, money raising for research seems like a worthy cause. We had committee mailings, two of them, December and January.

January had fewer papers than December because many people were on holiday. But someone on Reddit posted that the next one will be much bigger. So hopefully there'll be some additional progress there. But we can look at some papers that were in both mailings. The December one was post-Kona, and there were quite a few interesting papers that caught my attention. Some of them were new versions of the papers that we've discussed and some of them were new. This one was interesting. If you remember we discussed a universal function called syntax, a reduced version of which was proposed by Herb Sutter. And this document is a reaction to that and it's not a good reaction.

The author is Vilja Vutilainen and others. The title is UFCs is a breaking change of the absolutely worst kind. It begins with this quote. don't arise. They do. That doesn't help at all. So please read this paper carefully and keep your mind, eyes and ears open. Contemplate what it says and avoid those hasty reactions. And the abstract starts with this sentence. This paper explains why C++ should never, not ever adopt a unified function call syntax that can turn syntactic member function calls into calls of free functions, possibly using ADL. The proposal in question correctly says thus. is this fully backwards compatible without breaking existing code?

yes. But what that means is not a feature, it's a bug. It's a huge bug. And then they continue to tell that it's a problem because when the code changes meaning, it may continue to compile with a different meaning. And that is not in itself even the biggest problem. The proposal breaks an existing guarantee that all existing C++ has or thought it has a guarantee that a sizable portion of our users rely on. Some as a happy accident, but such a happy accident makes them very happy. And some as a deathly serious and intentional design choice. It breaks the guarantee that code that uses member function calls will never be subject to any of the complexity and woes of ADL."

So, looks like there's a strong objection to this proposal. Then they go on to illustrate some of the breakage examples. And yeah, I thought we had bad luck with the initial UFCS proposal, and now this cut-down version apparently also has strong opposition, so I'm inclined to think that we'll never get any UFCS in C++.

I'm sure it will result in some discussions in the committee, but I hear that the outcome will be negative as the last time. It's probably not a huge loss, but still would have been nice to have it. But, you know, backwards compatibility is the king.

I seem to remember reading a previous version of these objections, and I don't remember exactly but it did make sense at the time I know that some very smart people would like this to be added and there are reasons for that to make things like

design driven programming easier in a way so you'd have in a sense like when you play with templates you have some things that would happen in case there's some things that apply and you could simplify some complicated logic but it also does raise some difficult to predict edge cases. So yeah, this will definitely increase complexity. I can see that case for that.

Yeah. Yeah, we may be at a stage when it's actually right to ask, do we really need this feature? Does it add to the language or is it just another piece of syntax sugar, which is just going to make everything more complicated. Exactly. Oh well. It was a nice try. The next paper was a new revision of David Sankel's C++ should be C++ paper. There has been some discussion about it on Reddit. And the first Redditor says, there are many good points in this paper as many others will recognize, but I wish these issues would register better on the committee's radar. C++ serves the community better if it remains considered a viable language for new greenfield projects, and if it remains considered a viable language for teaching in the education

pipeline. The second point is, computer science as a field has yet to master how to best express algorithms in a way that can reconcile backward compatibility, incremental improvements, and breaking changes. Whenever there are advances in this direction, C++ should leverage them, because tools that help ease incremental improvements are vital to long-term viability. Some people then started naming all the problems with C++ that they experienced, which is the usual course of action in discussions like this, like the mention of the lack of Unicode progress. Although that is, I think, progressing quite well. Build problems, like always. A big section of the discussion is about random

facilities. But the paper itself is more general, of course, we discussed it. And the conclusion of the paper was, quote, this paper advocates for a C++ standardization mission, improving people's lives. It also identified the social and technical biases that abstract this mission. Finally, it considered major ongoing WG21 discussions and suggested ideas for future work. In the end, when I say C++ should be C++, I mean that C++ is a useful tool as it is. Drastic changes aren't helpful. To avoid it becoming what it is not, we need to say no more often, recognize our biases, and above all, put our users first." End quote. Here, here. Next quick note is about the paper by Matthew Bentley, Introduction of Stute Hive to the Standard Library.

I don't want to spend any time discussing it now. I just wanted to say that a single mailing in December contained three revisions of this paper. 24, 25 on this one, the 26th one. This is what determination looks like. Good luck to Matthew. You know, I think given his repeated effort across the years, I think it's a matter of when, not if. Eventually this is gonna get in out of sheer

persistence. Yes. Oh yeah, I think it's getting in. And one of the changes is a bit curious. They decided, if you remember the syntax, the simplest form was int x equals do curly braces return whatever 42 curly braces close. But now they decided against using the same return statement keyword for this. I'm guessing because they didn't want to introduce a new context sensitive variant of it because apparently it behaves differently or something. So they decided to use a new statement called do underscore return. I mean it's not like we don't have co for coroutines. so i mean once you started going that route it's like yeah whatever we can can you remind me what was the the purpose of this instead of just having inline lambdas so this statement does not introduce a new function scope.

There is no new stack frame, which is what allows external control flow to work. It's a prerequisite, as I understand, for pattern matching. Basically, it simplifies specifying expressions that are used in pattern matching and elsewhere. So it's like an expression that has a return type and return value, but it's not a function or a lambda because it doesn't introduce a new function scope. So that's my take on it.

It's a minor stepping stone towards having pattern matching and it is also going to be useful by itself, I guess, within functions, even if you don't use pattern matching. Let's see if they have something in the introduction. Yeah, so they say, quote, C++ is a language built on statements. If it's not an expression, loops aren't expressions, statements aren't expressions. When a single expression is insufficient, the only solution C++ currently has at its disposal is to invoke a function, where that function can now contain arbitrarily many statements. Since C++11, that function can be expressed more conveniently in the form of an immediately invoked lambda.

And then they proceed telling what's wrong with that approach. It's not always convenient because it introduces an extra function scope, which makes control flow more challenging. And no breaks or continues out of the loop, and so on. So yeah, it's a way to have multiple expressions as one. I think I need to read way more of this to digest this. For the moment it collides with my very small brain trying to interpret this as lambdas but not lambdas.

That's pretty much what it is. that the producer has lambdas but not lambdas. That's pretty much what it is. Not a lambda. Not a lambda. Fortunately, there's no other progress on pattern matching. It wasn't even mentioned in the mailings. So, sad face. Pattern matching is something that they wanted to aim for for 29?

It's aimed for 29 now. I think it was initially aimed for 23 and then 26. He's very optimistic. But then Michael Park, I don't know, stopped working on it, or maybe the work became slower. So it's unclear. Lack of progress at the moment. The next paper is Contracts on Lambdas by Timo Dummler. This paper proposes to allow pre- and post-specifiers on lambda expressions, which seems like a natural thing to have. They have this to say, quote, C++20 contracts did not allow pre- and post- on lambda expressions because it was using attribute syntax, and attributes could not be meaningfully applied to lambdas at the time. The cited issue was later resolved by adopting p2173 for C++23, which I think is the one that allows lambdas to have attributes. But then that issue

stopped, became relevant, because ContractsMVp no longer uses attributes like syntax. So it's like now it's pretty natural to have this. I think pre and post go after the parameter block and before the curly braces. I can't find it. Yeah, I think there was an example at the top. Oh yeah, I must have missed it. Oh yeah, this one. So capture block parameters, then any pre or post conditions, and then the body. Looks good to me. Yeah. What does it do if it's not satisfied? Oh, there's a whole huge paper on that,

how to handle various contract check failures. There are several modes and yeah, it's a whole huge paper this this one only discusses the syntax for for lambdas um that one is uh not for a single meeting it's like a lot yeah i think maybe that's the maybe that's the reference at the very top, this P29002. But if I recall correctly, there are behavior that you can enable with compiler's flag. And the standard behavior is that there's going to be a handler function you can customize.

And you can see that section 241 is ignore, enforce, or observe. Those are three semantics you can choose from. You can imagine what they would do. So there is a little bit of customizability there. And yeah, I think you need to specify when you compile with some sort of flag, but I'm not 100% sure. I think so, yeah. I think you're right. And somewhere there is a mention of this handler function

that's going to get called whenever there is a quote-unquote assertion. But this handler should be an emperor lambda because you don't want the same behavior across all your lambdas in the upper one class. I don't know about that. I think there may be a global function.

Because the exceptions, for example, could be proper way in most of the places, but in some places you may want to ignore. I don't know if you have to enforce the same behavior everywhere in the program. That I don't know. Yeah, there's a lot of detail to figure out, and hopefully they will do that by the time C++ 26 is released. And yeah, there is also conversations on what would be an error and what would be a bug.

So as far as I understand, we want to use contracts for things that are necessarily bugs. So things that you would definitely need a developer to fix and not something as an error that the program could naturally incur in like you would handle instead with exceptions or or with error codes. So only in the cases where you have something that is definitely a bug then you would want to use contracts for. Thanks definitely a bug then you would want to use contracts for. Thanks. Right, the next one I wanted to illustrate the struggle about choosing the correct syntax,

the best syntax for contracts. So this was the initial proposal that used the same syntax as the contracts in C++20, which was attribute-like. And this paper by Joshua Byrne, p2935, is titled An Attribute-Like Syntax for Contracts. an attribute-like syntax for contracts. It was released on the 5th of November last year. Don't spend too much time looking at that paper because it's already obsolete. The same day this paper was released by Joshua Byrne, Gaj Perazhman, Rostislav Khlebnikov and Timo Dumla. It's titled

An Overview of Syntax Choices for Contracts. And in the examples they basically go through various syntax choices including the attribute like and the natural. And this was what caught my attention. In the examples they say there are five distinct proposals for syntax to consider. And of those five, four are attribute-like with extra steps. Like attribute-like plus post declaration, attribute-like plus delimiters, attribute-like plus post declaration, attribute-like plus delimiters, attribute-like plus post plus delimiters, and then number five is natural. And I'm like looking at this and thinking it's much simpler to just use the natural because there's only one instead of four variants of the attribute like.

So yeah, maybe this paper also influenced some people who made the decision. Yeah, just go with natural. That's ambiguous. The next paper is Constant Evaluation of Contracts by Timo Dummler. Quote, This paper proposes semantics for constant evaluation of contract annotations. We propose that during constant evaluation, contract annotations should be evaluated with an implementation-defined choice of ignore, enforce, observe semantics, analogous to their runtime counterparts. In a manifestly constant evaluated context, a contract annotation with a checked semantic

and a predicate that is not a core constant expression renders the program ill-formed, while a contract predicate that evaluates to false emits a diagnostic. And they go on with some more details. Yeah, I can see how constant evaluation is a natural extension of normal contracts because we tend to have more and more things working at compile time.

I mean, why not? If it's possible, then it sounds great. Yeah, exactly. But then there's this quote. One of these design holes is the question of how contract annotations should behave during constant evaluation. Whether contracts are checked during constant evaluation should be implementation defined, allowing implementations to offer both options through compiler flags. The only difference is that constant evaluation has no compile time analog for installing a user-defined contract violation handler. As a user-replaceable function that is

added at link time, a user-defined contract violation handler is inherently a runtime-only feature. Yeah, that makes sense. Then they go and discuss to const eval or not or to not const eval. The first question that arises is whether we should consider contract checking during constant evaluation at all. And they say for many users the answer will be yes, and for others the answer might be no. And they end with this paragraph. The answer is therefore that we must give the user both options. So that's even more compiler flags to consider. But yeah, it feels natural to have it, so yeah. The next paper is titled Stead Quantity as a Numeric Type by Mateusz Pusch and Chip Hogg. And this is a second revision

of the paper that proposes introduction of units in the standard library. There are tons of units libraries, some of them better than others, but to have a notion of quantity in the standard library might be actually good. So was quantity something that they want to add on top of the units proposal or is it this a modification to quantity being an numeric type or something like that? This is like a unit. This is a kind of unit. So quantities would be like, herecquerel, Bode, some other units that have a notion of quantity. And you can combine them to get some other units. Quote, this subject is broader than it could be initially imagined.

Arithmetic operations are not only defined for user-facing types like quantity and quantity-point, but also for units and their magnitudes, dimensions, quantity specifications and references. So it's like type-safe numerals that express physical quantities. I don't know how to... In a nutshell, it's proven to you from adding apples and oranges together, so we should get a compile time error for that. Yeah, very well put. Exactly. I like that. Very nice. Thank you. So hopefully that progresses, we are going to have a reflection, luckily. And the changes in

the paper p2996, a reflection for C++ 26, is the changes that there are now links to Godbolt for examples, because EDG provided an implementation of it which is available on Godbolt. So that's very convenient and you can experiment with it. Let's see if we can invoke anything. Oh yeah, Compiler Explorer. Yeah, it's all implemented. You have to select EDG, parenthesis experimental reflection, and then all these weird syntax with square brackets and columns and carets seems to be working. It's very nice. And very weird looking, but we'll have to get used to it yeah it will take some getting used to yeah but yeah great you know i'm very happy that this is moving those people who for whatever reason brought their own c++ code passes are now panicking a bit, looking at this a bit.

Right, the next paper is version 0 of constexpr-stud-shared-petter. More and more stuff gets constexpr. The introduction says, quote, since the adoption of constexpr, I guess, in C++20, constant expressions can include dynamic memory allocation, yet support for smart pointers extends only to stdunicpter since C++23. As at runtime, smart pointers can encourage hygienic memory management during constant evaluation. And with no remaining technical obstacles, parity between runtime and compile time support for smart pointers should duly and intuitively reflect the increased maturity of the language

support for constant expression evaluation. Sounds good to me. Yeah, it's like a missing part. The more the better, you know. This is one of those at this point that if you can make it work and there is no technical problems with implementation, then I would say shut up and take my money. Yeah. The next paper is PE3075, revision 0.

Adding an undefined behavior and if NDR annex. This paper describes the process which will be used to write the undefined behavior and if NDR annex for the C++ standard. The previous paper P1705 enumerating core undefined behavior. I guess it was a Y paper, and this one is the How paper. So, yeah, enumerating undefined behavior is a useful thing to have in the standard, I guess. It's going to be a long list. Right. We have a post on the JetBrains blog

titled The C++ Ecosystem in 2023 Growth of C++20 Wider adoption of client-based tools AI gaining developers' confidence. Out of curiosity, does anyone use anything like LLM OpenChat GPT for writing code? I've experimented a bit, I haven't gone as far as bolting something like Copilot in or played with the JetBrains tools, just some little experiments.

It seems to really depend what language you're using, but a lot of the C++ I've tried, it's not been particularly good, but maybe I was overambitious. ambitious right i did a vba one that was really good vba yeah i had to do something in excel so just like wrote a lot of vba like do this for me and like it takes it gotta be at least a little bit of modifications, but I mean, it was very good. Nice. To be honest, if I ever have to write VBA, I will avoid it in any way I know. And that could involve...

It was for a personal application, like a small thing that I wanted to do for myself. It wasn't like really something huge or industrial. Yeah, that makes sense. Okay, I haven't tried it so I can't really comment, but I sort of dread it a little bit, because my feeling is that I will spend more time fixing the generated code and subtle bugs in it than writing the whole thing myself. discussing the results of a community survey that JetBrains did earlier. They have nice graphs and charts. So as you can see here in 2023 there's a like like 10% of people already using C++23. C++20 is increasing, but still so many people are using C++11. Maybe it's discouraging. Some of those

probably can't upgrade their compilers or operating systems or something. By bet a big chunk of those are working in embedded environments. But yeah, there's some progress. Interestingly this one says, which other programming languages do you use in your projects along with C++? And 45% said Python, while 29% said C. I fear some of them are using C slash C++. But Python seems like a natural thing to implement some sort of scripting additions to whatever projects you're working on. Yeah, it's a good combo, C++ and Python, I think. Yeah, just look at all the

AI frameworks, the core C++ and the user-facing interfaces in Python. Indeed. Which IDE or editor do you use the most for C++ development? 27% use Visual Studio Code, 26% CLion and 26% Visual Studio. So those are the big three ones. And the interesting thing is that Visual Studio Code has only been with us for, what, three years? Four years? Not long. Something like that.

But yeah, I moved from Qt Creator to Visual Studio Code, and I still have a soft spot for Qt Creator, but I don't know if it's moved fast in the recent versions. There were some iterations. I think it still looks a little bit old compared to Visual Studio Code. I hope, you know, there will be more competition. I'm happy to look outside of the Visual Studio Code setup that I'm currently having. I think that there is room for competition. Right. So this is a good moment to talk about this one. It's called 10x Editor. It's a C++ editor. Currently Windows only. And paid, I think it's like 80 bucks a year or something like that.

Eight bucks a month. But it's tailored for working with Visual Studio projects. And it's blazing fast. It has very nice IntelliSense-like features. It's got its own C++ parser. I would add this is not a sponsor. We're not paid by anybody. No, no, yeah, that's a fair note. I just found it and I'm following the author on Mastodon, following the progress, mainly because I like competition in this area and as nice as Visual Studio Code is, the thought that I'm using a JavaScript-based environment to write C++... Yeah, I'd rather try to ignore that thing.

Like, I lie to myself. But yes, I agree. It's basically like a browser. Yeah. So this editor caught my attention because it's native and is very fast. And I have no loyalty in my editor usage. I've tried most of them. And I'm currently trying a cross-platform editor called Genie, G-E-A-N-Y, which is is I think it's Qt based

and it's quite nice. Whereas if I had this one that would be really something. It would probably make a difference. I need to check if it supports remote execution,

remote debugging, because I need that but otherwise it looks pretty good. They have plans for cross-platform support eventually. I guess it depends on how well they do with their sales. But yeah, I guess they position it as a very fast alternative to Visual Studio at the moment. And I guess Visual Studio Code as well. So yeah, I'm watching this one closely.

Yeah, definitely keep it on my radar. So back to the blog post. How do you manage your third-party libraries in C++? Indeed, 25% of respondents say the library source code is part of my build. Fair enough, especially if a library is a header-only library, which is many of those. Most people, well not most, 21% use a system package manager and so on. I download pre-built libraries from the internet, 18%. I do not have any dependencies. 14%. 15%.

Lucky ones. Or maybe they don't realize they do, which is even worse. Maybe they like it for implementing the wheel. Yeah. Yeah, true. Build systems. CMake seems to be the most popular one. MSBuild.

It's kind of not really an answer because it's built into Visual Studio. XMake didn't make the list. Sad. There are lots of other interesting charts. We'll see what the 24 survey says and how it compares. Right, so Yussi Pakkanen wrote two blog posts on modules. I just wanted to let you know that he did that and he's not very happy with CMake support. And he's not very happy with support for modules in the current compiler versions. And also he's the author of the Mison build system. So I guess as a build system implementer he has his own problems with module support in

compilers. But judging by this Reddit thread, some of the problems he listed are being worked on. And judging by the overall vibe of the post and the reddit discussion, I would say the modules are currently not great, not terrible. So, they're getting there. Can't wait to do import std and forget about the include statements. Yeah. Same.

This is the post by Viktor Zverovich. It's titled Std print in C++ 23. Quote, This is the post by Viktor Zverovich. It's titled Std. Print in C++23. Quote. I just realized that 2023 is almost over and I haven't posted about the most important feature of C++23. Which feature is that, you might ask?

It changes the most important aspect of C++. The way we write hello world. And now in C++ 23 we write it as this include print and in the main std print hello world. I would say that's a very significant change. Std print is based on the foundation of std format in C++ 20. It's fully type safe, and the errors in format strings are caught at compile time by default. So if there is a mismatch, for example, a format specification is for a number and you're passing a string,

the code will not compile i am a big big fan of this and yeah i think beside all the positive things one can say about std print in general including the the things that you mentioned that you know you have compiled time checking of the of the formatting string and i think overall it will also have a positive impact on for newcomers to c++ you know because the first thing you do is you know add a word and maybe that's the point of this blog post and as soon as you have to explain cout and chevron syntax you know it gets like people thinking what am i doing here maybe i should rethink my choices of learning C++. So overall, I think it's a more welcoming syntax for people

that don't necessarily want to have to learn streams on day one. It's interesting. It's also much faster, at least the FMT format. We've got about 30% to 40 percent improvement over printf which is as printf which was kind of i was shocked when i saw that this thing actually improves and quite seriously on sees printf wow indeed you know it must mean that there is some magic happening at compile time on those format strings. I think overall really really good. I agree with this post, as the dprint is one of my favorite things. And not only that, it's extensible with user type support. It supports most standard types like containers, ranges, dates and times,

which are formatable out of the box. So you can just print a vector, for example, in a nice way. Not only that... Yeah, finally. Not only that, it supports Unicode. All you need to do is make sure that the String Literal Encoding is UTF-8, which is normally the default. And you can just use Unicode in your source and it will print correctly. That's very impressive. And as you said, as you said, Mihail, the performance is very good. Std print can write directly to SE stream. And yeah, this says here, FMT print is 20%

faster than pre-tef. Very nice. And the binary size is not hugely different, I think. So yeah, this is a great progress. Interestingly, Victor says, What's next? Now that we provide a safe, extensible and efficient formatting output facility, the next obvious frontier is formatted input. It poses a completely different set of challenges, but we could apply some of the lessons from

the stdformat and stdprint work." And then he says, what took you so long? Quote from Reddit, why did they need 38 years for stdprint? And Victor replies, I was too young to be involved with C++ 38 years ago, so I don't have full context. But the print function in almost its current form has been available in the FMT library since version 0.10 released nine and a half years ago. It took three extra years for it to print, mostly because Unicode on Windows is very broken due to layers of legacy code pages.

So yeah, I'm glad it got there. Right, we're almost out of time. And I'll leave you with this quote by Anonymous. A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. Right, that's it. Thank you for coming, and I'll talk to you soon. Bye. Thank you.