CppCast - Movable Iterators

Episode Date: June 20, 2019

Rob and Jason are joined by Corentin Jabot to discuss some of his proposals for C++20. Corentin Jabot is a freelancer developer and member of the French National Body and the C++ committee where he participates in the tooling, Unicode and library evolution working groups. He has been doing C++ for about 10 years and currently works with Mobsya, a swiss non-profit making educational robots for kids. News Catch v2.9.0 released Core C++ 2019 Videos Space Game: A std::variant Based State Machine Corentin Jabot @Cor3ntin cor3ntin Links p1207: Movability of Single-pass iterators p1206: ranges::to: A function to convert any range to a container p1634: Naming guidelines for modules p1628: Unicode character properties Sponsors PVS-Studio Facebook PVS-Studio Telegram PVS-Studio Twitter JetBrains Hosts @robwirving @lefticus

Episode 203 of CppCast with guest Corentin Jabot recorded June 18th, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com. In this episode, we discussed stood-variant state machines. And we talked to

Corentin Jabot. Corentin tells us about some of his proposals for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all right, Rob. How are you doing? I'm doing okay. Don't really have too much news to share with you No, nothing at the moment No immediately impending conferences or anything like that coming up

But we'll get back around to conference season soon enough I guess For me, anyhow Although we didn't discuss the fact that there's all kinds of conferences going on I mean, we're kind of mentioning that on the side but i'm not going to all of them no no one can go to all of them but yeah we will talk more about this a little bit but they just had the cppp conference in france and uh there's also recently the italian one too right yes they're on the same day yeah okay well at the top of episode like to read a piece of feedback. This week we got a tweet from

Sumit Bardwash saying he's listened through episodes 1 to 201 of CppCast and can now differentiate between Oogie and Loogie and EWG. Do we call it EWG Oog or is it just EWG? I think

it's just EWG. I don't know just a WG? Um, I think it's just a EWG. I don't know. Yeah. And, uh, and also what a set of improvements and standards conformance for MSVC. Uh, so yeah,

thanks to, for listening to all of our episodes. Uh, submit. Yeah. Uh, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook,

Twitter, or email us at feedback at cbgas.com. And don't forget to leave us a review on iTunes or subscribe to us on YouTube. Joining us today is Corentin Jebeau. Corentin is a freelance developer and member of the French National Body and C++ Committee, where he participates in the tooling, Unicode, and library evolution working groups. He has been doing C++ for about 10 years and currently works with Mobcia, a Swiss nonprofit making educational robots for kids.

Corentin, welcome to the show. Hello. I always like to ask, how did you get started with C++? So I did like a bit of C++ at university, but at the time I did like mostly Java. And I think it was Java 5. And I guess I got bored of university. And so I started to send my resume to this game company. And I think they liked me. And they told me, OK, we won't hire you.

But we want you to begin in two weeks. And also, can you learn C++ in two weeks? And because I was young i said yes and that's how i started with c++ because you were young you said i remember those days can you do this yes i can definitely do that just give me a week how did you go about learning c++ in like two weeks and how successful were you at it? I did both, beyond the C++ programming language book, which is the time I did both it in French.

Okay. And I started to read it and try to make my way to it. But then I guess like it still takes like months and months for me to actually start to actually understand what I was doing and then years to be somewhat efficient with C++. So did you actually read the entire book in that two-week period? Probably not, but I go through it a bit. And most of it is actually references. So it describes all of the SCL and so forth.

So the language side is reasonable. Right. So, yeah. So you did make a point of saying that you bought it in French at the time. Does that mean you would buy it in English today? Yeah, I actually have the newest, I think it's the fourth edition in English.

Because I tried to translate everything in French, but technical terms translated are a bit weird and so yeah i'm always fascinated by that the the the the technical translations of books yeah i guess maybe it's an issue that they don't have technical people doing the translations maybe yeah i've never heard of that being an issue but i i would think maybe if you have someone who you know speaks english and french flu, but maybe isn't familiar with C++, that could cause problems. Yeah, and technical terms

are supposed to be really specific, so when they translate it, sometimes some bit of meaning is lost. Right. Okay, well, we got a couple of news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about the work you've been doing, okay? Okay okay so this first one is uh another update from the

catch unit testing library they're now up to version 2.90 and it looks like the main change here is that they are uh adding a new type of benchmarking support, which they got from actually integrating from a different library called Nonius. That is what they said. I was not familiar with Nonius before this. No, I was not either. But it seems like it's an improvement. Yeah. I know from the Reddit comments that people were very pleased with that decision.

Right. There's another line item on here, though. Go ahead. Template test cases now support type lists. And I clicked on that issue, it's issue number 1627, and to see that it was someone asking for support for some macro that lets you pass in a type list and have that automatically expanded into testing the same template against multiple types.

And I'm like, wow, that looks interesting. But then I dug a little bit deeper to see that that's just an enhancement of an already existing feature that let you do something like that. And I'm like, I've been using Catch off and on for several years now, but I did not appreciate just how much it has grown in the tools that are available. So if you're using catch and you think, Oh yeah, I know catch. I've been using it for like three years, but you haven't like gone and looked at what the current features are. You probably should. Okay. That's good advice. Yeah. I haven't taken maybe that close to a look at it in quite a while either. Okay. Uh, next thing we have is that the core c++ uh conference which

was in israel a couple months back uh now has their youtube videos online or at least some of them looks like they have eight up so far and they had definitely had more than eight uh classes right jason oh yeah there were definitely more than eight sessions oh wait uh well there are two tracks for two days yeah yeah it's definitely more than eight yes but looks like your uh your keynote is already up here it is yeah so i i am way behind on my conference video watching i think the last thing i watched was uh herbs accu talks i'll have to start catching up with some of these yeah i haven't gone and watched any of the videos. I know that mine is up, and I can't watch my own,

so I didn't watch it. I did watch it, and it's pretty great. Oh, good. Thanks. Yeah, and I like that you show the evolution of C++, and we can see that C++ is becoming basically a better version of itself over time. So yeah, it was a nice video. Yeah, I had a concept in mind,

but when you're preparing a talk, you don't always know where it's going to go. And then as I got like three quarters of the way through it, I'm like, wait, the language actually is getting better with each version. That's pretty cool. We are trying to do that, yeah. So it's great to see that we are

succeeding okay and then the last thing we have is a post on Bartek's blog and this is I think from a guest post, guest first yes from Nikolai Wutke and it's about

a variant based state machine with this example of a space game. And I thought this was a pretty good example of how to use std variant in making a state machine. Yeah, I hadn't seen it written out in such a way before. And so really good example. I'm curious, question for both of you. Are you used to using a state machine for managing the state of your project? I'm not too familiar with their use, but I

like this example. How about you, Brandon? Yeah, I don't do that often, but what I found funny about this blog post is that they have the overloaded function. I don't know if you ever tried to define overloaded to pass

a set of lambda to visit, right? Right. And I think there was a proposal for that before the committee at some point, but it never got through. And everyone implemented the same exact things because you cannot use lambda with visit otherwise.

So it's, yeah yeah and it's like I think four line you probably implemented that too right yeah I've done a C++ weekly episode about it and C++ 17 it's like literally four lines in the most first possible way yeah I just on my the last

project that I started I did try using a state machine but I've never used a state machine before. So I kind of just, you know, was flumbling around trying to figure out how to best do it and was like, Oh, wow, this makes a lot of sense. Now I know exactly what state the program is in at any given moment. And I feel like this article did a great job of kind of filling in some of the pieces where I could have done things better than what I had done. So I strongly recommend this article for our listeners to go back and read it. Well, Corentin, let's start off by just telling us a little bit more about the work you do

as a C++ freelancer and this nonprofit making educational robots. That sounds pretty interesting. Yeah, so I'm basically a freelancer because I'm in France, they're in Switzerland, so it was basically easier to set up that way legally, I guess. And so what they do is that they have this little robot which is quite small, and it's just basically motors and LEDs and some sensors. And they sell that to schools for, like, children from six years old and more and try to do, like, programming with, like, visual blocks and something on desktop. So it's pretty interesting. And, yeah, so it's actually quite old design at that point. So the microchip that's in there is actually 24 bytes, 24 bits, sorry.

And so it's kind of a pain to work with. 24-bit architecture? Yeah, yeah, yeah. Which CPU is 24-bit? It's an old microchip. Okay. And so basically, it's like a 32-bit microchip with one byte disabled somehow. Okay.

So it's a pretty nasty thing. And so the firmware is mostly C. And of course, it's like GCC 4.5 or something. So it's kind of old. But I'm mostly doing desktop applications with SU and C++17. So that part is pretty nice. So when you're in a standards committee meeting

and someone is like, well, can't we just define integers always being at 32 bits? And you raise your hand and you're like, no, we can't. Yeah, that would be nice, but yeah. But I mean, I don't think it's really much of a problem because basically this weird architecture

don't really update their tool chain. So they will probably stay to GCC 4.5 forever. And they will probably never care with C++ that much, unfortunately. And so, like, it's not really a problem for the community. So the community does care, right? And they will never, like, decide that

int is 32-bit. But in practice, like, people never update their toolchain, so I guess we could do that if we wanted to, right? Right. So how successful has the project been, actually, with the school I guess we could do that if we wanted to, right? Right. Yeah. So how successful has the project been, actually, with the school kids?

I think, like, it's great. So teachers really like... We try to make something simple for teachers, and sometimes, like, kids are actually better at using that than the teacher. And, yeah, so kids, like, can understand, like, programming. Like, it's natural for them, and teachers, like, sometimes struggle. Yeah, but so they try to,

they make, like, I guess, like, I don't, like, interact with kids directly, so I don't, like, really know what's happening in classrooms. Right. But I learn a bit of logic and a bit of math and a bit of programming.

But it's really simple, right? They don't do C++ or anything of that nature. But I guess it's great for them to learn math and logic and that kind of thing. So you said it's like a visual programming language, right?

It's Scratch. I don't know if you know it is scratch yeah yeah so yeah so they can drag in blocks let's say like the robot whatever yeah it's fun kind of want one yeah i definitely would have wanted one 30 years ago when I was a kid, there's no question. Yeah, but it's a difficult market. There's a pretty successful company in America called Anki, I think. I don't remember if that was the name of the robot or the name of the company. And they had like hundreds of millions of investments from Disney. And they were doing facial recognition and really something

really advanced that we don't have that. And one day they shut down completely overnight. So trying to do something with cool is quite difficult. As we just mentioned, the CPPP conference

was this past week. Were you able to make it to that? I was able to make it to that, yeah. How was the first conference? It was pretty great. They have a great list of speakers. I think they contacted the speakers they wanted directly.

They had Kate doing a keynote. And Anna Duzivoskav did a CTRE talk, which apparently she modified again from the last time she did it. She does an amazing job of updating it every time, yes. Yeah, yeah. And so now Slider, even more dynamic than before.

Wow. And, yeah, to the point that people ask a question about their slide, right? They care more about the slide than the stereo itself.

And Odin did a talk that I think it's the same talk that he gave at CppNo about using DSL and functional programming. And there was a talk. So the thing is, like, it was a one-day conference,

and I still have to choose between different tracks because there are two tracks, and every single track was really great. So that's a topic I didn't see. So I know that Simon Brand tried and succeeded in implementing a compiler

a Brandfell compiler in 15 minutes and apparently it was successful and that was great and yeah yeah I wouldn't try that yes but so it was really great, and I think there was 150 people.

So someone, I think, noticed that actually more people in CPPP than at CPP now. That would be probably accurate, yeah. Yeah, so it was pretty great, and I think they are doing one next year. Did they already announce the dates? Yes, no, but it's pretty great. And I think they are doing one next year. Did they already announce the dates? Yes, no, but it will be June. So around the same date.

And this time they will do a call for proposal. So if you want to visit France, Jason, I think, yeah. I might have to submit to that one. So I put out a challenge on Twitter for people who were attending either C++ Italy or CPPP Paris

to try to attend both of them. And did you try that? Did you try to fly between Milan and Paris in one day or anything? I did not try that, and I think like Fred, I don't remember his name, but one of the organizers did the joke during the opening statement

that if people wanted to go to Milan, they could. But, yeah. But I think, like, next year it will be actually two days. Okay. So, yeah, maybe it will be more. Yeah, and I'm impressed. 150 people. Yeah, I mean, C++ now has a hard limit of 150.

They can't go more than that because of the venue. Okay. But, yeah, so that's pretty crazy. Yeah, but it was fun, so. Very good. I want to interrupt the discussion for just a moment to bring you a word from our sponsors. PVS Studio is a tool for detecting bugs and security weaknesses Very good. bit, 64 bit, and embedded ARM platforms. The PVS Studio team writes a large number of articles on the analysis of well-known open source projects. These articles can be a great source of inspiration

to improve your programming practices. By studying the error patterns, you can improve your company's coding standards, as well as adopt good programming practices which protect from typical errors. For example, you can stop being greedy on parentheses when writing complex expressions involving ternary operators. Subscribe to Facebook, Telegram, or Twitter to be informed about all publications by the PVS Studio team. Links are given in the podcast show notes for this episode. So you've been involved with the Standards Committee for a while now, is that right? Since Rapperswil, so a bit more than a year, I think. Okay. Do you have any active proposals you're working on?

I do have 12. 12? Yeah. Okay, go ahead and list them all out. No, I'm just kidding. Yeah, so I don't really know how that happened, but I think the last mailing, so before Kona, I had the most number of papers in the mailing list. And this was really not intentional, but it happened, yeah.

Really? Yeah. I thought that was Izzy. That was before San Diego, right? She had the one before. Oh, okay. Okay. Yeah. Do you get an award at the standards meeting

if you submitted the most papers, or do they kick you out if you submitted the most papers? It's more like, yeah, I guess that you have to do wording for your paper afterwards, so it's like a lot of work. So it's like, I don't frequent having too many papers in committee meetings, because at some point I was running between them, and it's like I don't frequent having too many papers in committee meetings because at some point I was running between rooms and it's like exhausting.

And even like keeping track of all the papers is work in itself. So, yeah. But we have like something called the Wong number. It's in reference to Michael Wong, who is a committee member. And he's a share of multiple groups. And I think he holds the record for the most paper. And so we compare to that.

But yeah, it's really not... I mean, it's really not authorized because it's a lot of work. And so yeah, I definitely don't recommend having more than a manageable number of papers. But yeah, it did happen. Yeah, I definitely don't recommend having more than a manageable number of papers, but it happens. Well, if you've got 12, you said that you're actively working on it.

What's the most significant one in your mind? What's the one you are spending the most time and effort on? Okay, so that would be... So I'm really bad at remembering numbers, so people in the community can say this number and they understand I really cannot do that but I have a paper I think it's like 12

1207 that is movability of single path iterators and it's like took me the longest time to work on it and I've been working on it for basically a year. And it's basically a one-line change. And it does modify one concept in the hierarchy of iterator

concerning concepts to make them not require to be copyable. And that allow you to have a move-only input iterator. Move-only input iterator, okay. And the idea is that if you have a file or a socket, you cannot have a copy of that, right? I mean, you can...

You have to think about it like a reading aid, and so you only read it from one place, and if you try to make copies, and you read it again, you will have the same, not the same value, right? Because you will already have advanced new file. Right. And so making the iterator move only, it's safer, basically.

Okay. So a new category of iterators that are moving. So it's not, yeah, so someone else proposed a new category of iterators that are moving on. So it's not, it's not, yeah, so someone else proposed a new category of iterator, and, like, it's really not, so it doesn't really work. So it just, you don't, so it's still a new put iterator that you don't have to copy. So it's really just a concept that changed. And so I talked to some people, and they wanted to do that for a very long time, and they couldn't because it would be a breaking change

to remove some requirements from e-theaters, right? And we had a unique opportunity in 2020 to do that because we are adding, like, actual concepts and the range library, and so everything is, every requirement of e of ethers and we have since 98 we are making that into actual concepts in a new namespace so we have a unique opportunity to fix that now and so either this paper will be approved in colon until it will be dead forever right because once c++ 20 ships we cannot cannot modify any concept ever. Oh, wow. Yeah, so concepts

are really scary because you can never remove anything from them and you can never add anything to them because that would break overload sets. So when you make a concept in the standard library, it will never ever change. Otherwise, it's like a

crazy API break. Right. Yeah. I mean, fortunately, some of these things like iterator categories and containers types have been pretty stable for decades. Yes, they have, but they are changing quite considerably in 20, right? Okay. So, because Eric Nibler and Casey Carter did a lot of work

to make E-Theatre work properly with reference type like Victor Bulls and this kind of really nice container. And so we changed some definition and some some requirements okay of the of the concept right and i'm adding to that so yeah so for most people and most cases it will be the same but in some cases uh the requirement will be slightly different and uh better right so we try to with it like i mean so most people see, like, ranges as just a pair of iterators, something like to write a sort

algorithm called better, right? But actually behind the ranges proposal, there are like a lot and lot of work to really specify the requirement of everything as best as we possibly can and, like, be really meticulous about it. So I think that's

a great benefit of the range proposal that most people won't care about. And the end result of that is if you have a vector of bool and you try to figure out something it will just work because of that work. So, yeah. It seems just remarkable how often

an argument involves because vector of bool. Yeah. It seems just remarkable how often an argument involves because vector of bool. Yeah. And I know that some people are trying to get rid of it in the future. So I think Jean-Yves Meunier is trying to work on that. But it will be a while before that can happen. And I think, to be fair, it becomes the will be a while before that can happen. And, you know, I think to be fair, I mean, it becomes the

punching bag for a lot of these things, but it's representative of anything that has to return a proxy. Yeah, exactly, yeah. And, I mean, that's not the only use case for returning a proxy for your iterator. It is the only use case in the standard.

In the standard, yeah. Other people have done their own things, I would assume, anyhow. I think I have. Yeah, probably. But making that work is really, really hard. Right. So is this proposal,

do you think it's going to make it into C++20? I mean, you're saying if it doesn't, then it's kind of dead. Yeah, so most of my proposal at this point, so last meeting was Kona, and Kona was the feature phrase, right? So theoretically, there shouldn't be new proposal. And so this proposal was accepted at Kona by Library Evolution. Okay. And now it is in between Library Evolution which is a design group and

Library Working Group which is more of a wording group. So most of my paper are between these two groups. And so now it's a matter of doing the wording in time and that's in time means before the end of the colon meeting, basically. Which is soon, right?

Which is in 14 July, something like that. Okay. Yeah. So, yeah. And the deadline for that meeting was Monday. Oh. Yeah, so actually I spent my Monday finishing the best I could on my paper and sending them to, yeah. So, you know, this is the one you've been spending the most time on, you said,

but if you have 12 papers, how many of them did make it through, you know, the Lugie group or Oogie group? So I did like have, I don't remember how much, but maybe I think I have seven or something papers between Loogie and Loog. Okay. Sorry, between Loog and LWG. Okay. So seven that are currently still being worked on.

Yeah, seven that are waiting for a wording review. And could potentially make it into C++20. Yeah, something like that, yeah. And I have a few new papers for C++20, but yeah, but most of that work is trying to make ranges work with

existing container type and span and string view. So it's like trying to finish ranges the best we can and dotting the i and crossing the t on everything. So it's like not a big feature, but it's... Well, so you're saying

at the moment, ranges would not work with span and string view. So you cannot have a span over a range. So if you have a contiguous range, you cannot have have a contiguous range, you can have currently a span over it or a span over a pair of iterators.

It doesn't use concept at the moment, so it tries to define how you can construct a span over a container, but it's a bit of a nasty definition. So I have a paper to permit that and the same thing for SpringView. And it both comes down to the permit that, and the same thing for SpringView. Okay.

And so, yeah. And it both comes down to the fact that they're required to be contiguous containers. Yeah, you do have to require contiguous range. So this is like a new concept in 20, contiguous range and contiguous iterator. Okay. And you need that because a span is really just a pointer and a size,

so you need to make sure that your underlying elements are contiguous in memory, otherwise you'll point to nothing. Right. Yeah. I think this might be a moment worth maybe mentioning for our listeners. So something like a list, you can have a begin and end iterator, and the elements of the list can be everywhere throughout memory. You have no idea where they are.

But with array or vector or string or string view or span, you know that each element is immediately following the previous element physically in memory. Well, logically in memory, I guess, because the operating system can do whatever it wants to, but that's what we're talking about, right? Yeah, exactly. So, yeah, so there was that.

And then I have a paper with Casey and Eric. So you know that views in 20 are lazy, right? Oh, you know, I'm only vaguely familiar with ranges and views, honestly. Okay. Yeah, so when you do, like, when you have, so oranges is basically just a pair of theater, right? So it can be a container, honestly, but yes. Yeah, so when you do, like, when you have, so a range is basically just a pair of iterators, right?

So it can be a container, but it doesn't have to be. And all of use, like, transform or drop, text, or IOTA, these things are lazy, so they don't they operate on their element as you move over the range,

but they don't, don't take any memory. You never have the full range in memory, so that allows you to have, for example, infinite range, and you can just iterate over that and never use any memory, basically, except for the one element you are trying to work on. But sometimes you want that view to be... You want, actually, to commit that view in memory and so we have

a proposal to convert any view to any container with a ranger adapter so you would like say take your view, do your transformation with the pipe syntax that we have in rangers and then just pipe that to a function that's

called to and to vector and it will like take that views and create a vector out of it. And now you have a vector in memory, and you can keep that vector. I don't know if that makes sense. It does, but I'm wondering if you have to tell it the type of vector, or if you can somehow deduce the type of vector that it needs to be. So it's quite magical.

So you can tell it the type. If it's, if it can, if the same type is the same type, it's fine. If can also do implicit conversion. So you can have like a views of ints and put that in a view of long, in a vector of long that will work. Right. And it will work with maps

and associative containers too. If you have like a view over like pairs, it will convert that to a map and so forth. So it works in either case. So you can specify the type, but you don't have to. And yeah. And now I'm curious because I'm not familiar with all 12 proposals that you have in flight.

I did look at some of them. Since with your interest in ranges and iterators and move-only iterators, do you have anything in flight to deal with this issue that initializer lists are const arrays and we always have to copy the data out of them? It seems like a use case for like move iterator move only I don't know so I don't have a paper for that and I don't think like anyone does

and the issue is that initializer list is in read only memory in your binary right so you cannot like move from it because it's in a part of memory of your executable that you can not modify. I think that's the reason why it's only my copy.

I may be wrong, right? Because it's not something I'm completely familiar with. But I think that was one of the reasons why it's not possible. Certainly. Yeah, I'm sorry. Go ahead. No, no, go ahead. I was going to say an initializer list of trivial types,

yes, they'll probably be in read-only memory, but if it's anything that isn't trivial, then it can't be, right? Like, initialize a list of shared pointer, for example. I don't think that could ever be compiled into read-only memory. Yeah, probably. I actually don't really... I think there was this issue,

and I'm probably in one other issue, but I know that people have looked at it, and I don't think it's possible, but I may be wrong. Yeah. But you make a good point. I don't know. Yeah, me neither.

Yeah. I will try to ask someone who actually knows what they're talking about yeah so one thing oh go ahead yeah no go ahead i was gonna say one thing i was curious about is i think we talked about some blog posts of yours that you made late last year about um improving modules and i was wondering uh what your opinion is on the kind of final state of modules that's going into C++20. Yeah, so I'm not really happy with modules as they are, but

they are in the standard, and so now we have to, like, deal with the fact that they are there, and I don't think, like, it would be useful to try to stop it at this point. But, so, what we did at, so the issue is, the issue with module is that...

One of the issues with module is that it's quite transformative in the C++ ecosystem and existing tools and build system, ID and so forth are really not equipped to deal with module, right? And some of these things are... like, people never rewrite their build systems, so people are using Mac and AutoTools and all these things that are really not designed to handle modules.

And so what we, and we try to modify maybe the language to make things easier, and we realized with some people at Kona, I guess, that we would get nowhere. And so with Pinter Bindels and René Rivera, we decided at Kona to make a proposal for a separate document that would be the technical reports for modules and how to use module in your code and that was quite well received by everybody involved so before that there were like some conflict between like tool people and compiler people so but i think like everybody at the table like like this idea of making like a separate document so that way we don't have to care about tools and actual source files in the standard

because the standard doesn't even accept that there are files, right? And so it's really made for... You can program your C++ program on your sheet of paper and compile that. So it's really abstract. And so there like a joke going around that Richard Smith is a valid C++ compiler implementation. Yeah, because

it knows the standard. So you can actually write, use a sheet of paper to compile. And anyway, so what we decided to do is to make a separate technical report. And that was really well-received. And now we have meetings every two weeks to decide what we are doing with that.

So I'll actually implement modules in both compiler and build system and make sure that can work together. So I don't know how that will go. I still have some reservations, but I think that we might be in a better place than we were like six months ago. And you said you've been meeting every two weeks. Something like that, yes.

So Bryce Leback, I'm saying everybody's name terribly, but so Bryce Leback is now the chair of the tooling group. You're mostly talking about people we've had on the show, so... Yeah, yeah, I know, yeah. So... And so he's, like, trying to drive that. And at

this point, the tooling group is really the module ecosystem group, so we don't, like... We stop, like, carrying with anything else. So we try to focus on modules to make sure that modules are a success story after 20 days. It probably is the most important thing right now.

Yeah, I think it is. So we are trying to focus on that and making sure that we find solutions that everybody can agree on. And CMake people are trying to implement module in CMake and in Ninjas and so forth. So it's going pretty well, hopefully. So you're pretty happy with the status of this document so far.

I'm guessing this should be released alongside C++? It will probably be after. After, okay. At this point, we have nothing in the document. We are still trying to figure what we say in it. But the fact that everybody at the table is, like, encouraging. So, yeah, we'll see how that goes. One of your proposals that has caught my eye,

I think each time I've seen it come up in the list of committee papers, is deprecating the comma operator in, how is it worded? In subscripting operations. Yeah. Can you explain that one? Okay, so if you have an array, right, and you can index it, right, and you can have a comma in there because you can have a comma

everywhere. Because it's C++. Because it is C++, right. And that probably doesn't mean what you think it does right it's like the coma operator is something that people don't really expect right and the reason of that paper is that

in so not in 20 but probably in 23 there will be MD span so MD span is like span but multi-dimensional so you can have a vector you know something like two-dimensional or three-dimensional, maybe something like to represent a 3D space or something. Right.

And there are also people working on linear algebra, and they are trying to make a matrix type. So this can also be multidimensional. And now there is the issue of how you index that thing right and you cannot use the subscript operator because that operator only support one dimension right right and so what they are doing is they are using the call operator because the call operator is the only operator that we have that you can have multiple arguments to it. Right, and you're talking the parentheses versus the brackets, basically. Yeah, the parentheses, yeah.

Okay. And the reason I wrote this paper is that, first of all, like, having parentheses is, like, not really readable. So you don't necessarily understand what your class is doing. If you see parentheses, what are you calling? Right. And so that is an issue. And the other issue is that we are trying to, and I guess we are trying to do that to, like,

teach people not to use operator overload for some things they are not designed to because it becomes not maintainable and difficult to understand. And so if the C++ community starts to use operator to do some things that they were not meant to do, people will do that too, right? Because some people think that the committee is a gold standard. And so if you start to do something that is maybe a bad practice, people will do it too.

And they will say, yeah, but the committee is doing it. And so deprecating this comma in subtractive expression will let us hopefully remove them completely in 23 and having this new semantic where you can have multiple index for multiple dimensions. And then you can say you want to have a matrix or a geometrical space of some kind, like a picture. If you want like a specific pixel on the screen you can use that uh multi-dimensional uh operator i guess so that

is um that was the goal of the proposal and it was it was accepted by uh both evolution and core so the wording is the wording is done, and everything is accepted, but there was some clear cal error. So it was actually not voted on in Conan, but I expect it will be in colon. So it should be in 20, and compiler will emit a warning for that. So the first step is to deprecate it, and you still

haven't yet actually added the ability to have multiple parameters in the subscript operator? No, we did not, and I am hoping that we can do that in 23 at the same time as we do mdspan, but

this will be quite difficult to convince people that we can both remove, add a new semantic before we got a chance to actually remove it. But so we'll see how that goes. But I expect like a lot of people to actually use MD-SPAN because I've spent, I spoke to people in like a lot of different industries that are really exciting about MD-SPAN because it's down to that it is useful like for audio, for image manipulation, for any scientific software and so forth. So a lot of people will be using that.

So I hope that we can have, not parentheses in MD-SPAN by 2023, but it will be difficult, right? We'll see. So what I did is that I actually looked for this pattern in every open source library that I could find, and nobody is using it besides one file in Spirit that is deprecated. So we don't expect this to break anyone's code,

and this is why we can deprecate it, because we know that it's not something that people use. So I just have to imagine, because it's Spirit, they're probably using an overloaded comma operator inside of an overloaded subscript operator. Yeah, exactly, yeah. Yeah, okay. And if you're listening and you don't know what that meant,

just be glad that you don't understand what they're doing. It's fine. Yeah. Okay. Are there any other papers that you're working on that you wanted to highlight? I did, with Robert Douglas, we did manage to pull a source location out of a library fundamental limbo that it was in. So because papers that go into library fundamental, like, they get forgotten. But so we will have, like, source location, which is a replacement for line and file macros.

Okay, right. And so, yeah, so I have that, and this is pretty cool because I have this crusade against the preprocessor, and I'm hoping that we can, at some point, not need to have a preprocessor in C++ anymore. This will take some time, but this is one part of that. So that's pretty exciting. That's cool. And yeah, so I have that.

I have a paper about Unicode properties. But Unicode, maybe 23, maybe not. We'll see how that goes. But a lot of work to get Unicode in C++. So yeah, and I think that's about it. Okay. As far as my paper goes, yeah. Okay.

Aside of your own proposals, what are you most looking forward to with C++20? Aside of my own proposal? I don't know. Like, so I'm pretty excited about concept and ranges, obviously. And I guess co-routine. Co-routine are really, really great. And I think they will make

a lot of code, like networking code and anything that is asynchronous much more simpler to write and teach and to maintain. So that's really exciting. CoRoutine have been a battle in the committee for quite a long time

and I think we voted on CoRoutine like three or four times before they were finally accepted. So yes, that's one of the exciting things of C++20. But I mean, there are so many things in C++20. It's by far the biggest release of C++. I think it's probably bigger than 11 at this point.

Yeah, that's probably true, yeah. Yeah. And I guess for you, Jason, we have even more constexpr things you can play with. Yay, constexpr. Yeah, everything is constexpr now. Yeah, I'm really looking forward to that with some of the algorithms specifically.

Yeah. And you can also have some constexpr allocation, which is quite... probably will be quite useful to be able to use like vector and string in constexpr. Yeah, that would be game-changing in some contexts.

Yeah, I think it will, yeah. Okay, well, it's been great having you on the show today, Corentin. Okay, thank you for having me. Thanks for coming on. Yeah, thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast.

Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website

at cppcast dot com. Theme music for this episode was provided by podcast