CppCast - San Diego LEWG Trip Report

Episode Date: November 15, 2018

Rob and Jason are joined by Ashley Hedberg to discuss the San Diego C++ Committee meeting from her perspective on the Library Evolution Working Group. Ashley Hedberg has been working at Google for the last three years. She currently works on Abseil, an open-source collection of C++ library code designed to augment the C++ standard library. San Diego was her second WG21 meeting. News How to Write a Good Proposal to C++ TL:DR for #CppSan CppCon Videos and Lightning Talks Ashley Hedberg Ashley Hedberg Ashley's GitHub Links 2018 San Diego ISO C++ Committee Trip Report C++ Current Status Abseil #include Sponsors Download PVS-Studio We Checked the Android Source Code by PVS-Studio, or Nothing is Perfect JetBrains Hosts @robwirving @lefticus

Episode 175 of CppCast with guest Ashley Hedberg, recorded November 14th, 2018. Today's sponsor of CppCast is the PVS Studio team. PVS Studio can be considered both as a tool for finding errors and typos, and a static application security testing tool. The tool supports the analysis of C, C++, and C- C Sharp code. 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 discuss how to write a good C++ proposal.

Then we talk to Ashley Hedberg from Google. Ashley talks to us about the San Diego C++ developers by C++ developers. I'm your host, Rob Irving,ined by my co-host, Jason Turner. Jason, how are you doing today? Doing all right, Rob. How are you doing? I'm doing okay. Last week you were doing some travel. This week I'm doing a little bit of travel.

How was your Austria trip? Yeah, it was pretty good. I think, well, the class that I taught went well and the lecture that I gave at the university went well. I think there was a little over 100 people or something that came, and it was pretty cool. And that was just people who heard about it from Twitter? Yeah, Twitter and their local university announcements and stuff. Most of the people there were people that went to the Technical University of Graz and had taken classes there and then were aware of it because of the local meetup

and that kind of thing. And one person came by and talked to me later and told me that he had taken the bus from Vienna to come to my talk, which I was like, that's like a two and a half hour bus ride. Thanks for coming. That was pretty cool.

Yeah, that's awesome. Okay, well, at the top of our episode, I'd like to read a piece of feedback. This week, we got a comment on the website this is from cameron tavacoli apologize if i butchered that name but he writes uh thanks to both of you for this fantastic podcast series and the great guest lineups keep it up i feel so much more productive during my commute i keep discovering new sources of info thanks to your episodes cheers Cheers. That's from Montreal, Canada. Yeah, very cool. Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Ashley

Hedberg. Ashley has been working at Google for the last three years. She currently works on Abseil, an open source collection of C++ library code designed to augment the C++ standard library. San Diego was her second WG21 meeting. Ashley, welcome to the show. Thank you for having me. I'm excited to be here. Abseil is a big project, right? Yeah, we've been working on it pretty consistently for the last two years, maybe three even. I joined the project about a year ago, right, as we were launching at CppCon in 2017. Okay. And we've been releasing additional libraries. Our Swiss tables just came out,

so we're very excited about that. And we've got more stuff coming soon. I'm sorry, did you say Swiss tables? Yes. Swiss tables is Google's faster HashMap implementation. Oh, okay. Oh, I don't think I've ever heard that name before. But was there presentations on that at CppCon last couple years? Yes, Matt Kulikandis presented on them. I can't remember if it was in 2017 or 2018. Sounds I believe if my memory serves me as 2017, but I didn't realize that was the name. I believe you're correct as well. They were developed in Switzerland, so Swiss Tables.

Oh, like Swiss cheese. No, I'm just kidding. Actually, since my brother is Swiss, it's kind of funny because, you know, from their perspective, they're like, you know from their perspective they're like you know that there's like 300 varieties of swiss cheese right what you call swiss cheese in america is you know like a variety i'm like yeah yeah okay well ashley we got a couple news articles to discuss uh feel free to comment on any of these then we'll start talking more about all the news coming out of the san diego iso meeting okay sure okay so this first one is a blog post from janhid manid who

was a recent guest over the summer and i believe he was also at the san diego meeting and he wrote this article about how to write a good proposal for the c++ uh standards body and i thought this was a really good post. He kind of is putting out a lot of advice based on his experience writing papers. He's very self-deprecating in it, which is very funny, although he's writing excellent papers from what I've read. Yeah. But yeah, it seemed like very good advice.

Survey the industry, make sure you're putting in code samples, make sure you're putting in what the intent of your paper is, not just the standard ease. That's kind of less important, at least with the first revision. So this makes me curious. Ashley, have you submitted or been involved in any proposals? I have. I believe there are three of which I am on the author line, And I can agree with one of the other headings in this article. It will suck very much. But if it's something you're passionate about, it is a fight worth pursuing.

That's cool. Yeah, I mean, I'm listed as an author on a paper that went to the committee, but I really didn't have anything to do with it. So I don't have any input on this. Well, since you are involved with three papers, you said said ashley do you think this all sounds like good advice yes all of this is very good advice i received very similar advice when i started writing my papers as well and i'm glad someone has written it up more formally for the rest of the world to see. Okay. This next one we have is a TLDR post, kind of a TLDR trip report

based on the San Diego meeting. And it's kind of all the highlights that went into this meeting and a couple kind of code snippets to show what's going to be changing with C++20. And obviously we'll dig more into this with you in a moment, Ashley,

but was there anything anyone wanted to call out from this? Oh, well. I mean, we're going to be talking about some... Is it worth doing a slight preview as to what our plan is here, Rob, so that it's clear? Sure.

So, I'm worried that something might happen, but our plan is to have two Trip Report episodes. So we have Ashley this week, and our plan is to have two Trip Report episodes. So we have Ashley this week, and we're going to have another guest this week. And Ashley, you were on the LEWG group, and our other guest was more on the EWG groups. So hopefully that second guest will happen. But yeah, we're kind of splitting up the Trip Report because so much seemed to have happened at the San Diego meeting.

Right. splitting up the trip report because so much seemed to have happened at the san diego meeting right so today we're going to focus more on the library and plausibly next week more on core language changes right okay yeah so i i'm reluctant to like oh there's all these things because we'll talk about them in a moment and then we'll talk about them next week. So I don't know. Yeah. Okay. I will say there's one thing on here that just as an aside, like nested inline namespaces, this is a good article just for the record. Nested inline namespaces, I have to admit, I've never used an inline namespace and I don't actually know what it's for.

So I don't know why I need a nested one. So AppSale actually uses inline namespaces in its long-term support branch cuts. Obviously, AppSale is trying to push the whole live at head thing, but some people can't or don't want to do that for a variety of reasons. And so we cut every six months like a stable, you can depend on this and we're not going to change the API and make you update your code or anything like that. And so we put inline namespaces in those branch cuts, ideally so that if you try to link two different LTS versions into the same program,

the fully mangled name of say string view and both branches will be different. Okay. So you would type absolute string view in any of your code, but you could link in say the June branch cut versus the December branch cut, and there would be a different mangled name for StringView. So you don't ever type the inline namespace as a user, but it tries to do, like, I'm not fully sure how it works,

but it messes with name mangling so that things don't stomp on each other as much. Okay. And then I guess with that in mind, if you tried to link two different things together that were using two different versions of the library, you would presumably get a linker error at some point. Ideally, you would get a linker error rather than everything starting and things just going haywire at runtime. Yes. Linker error is better everything starting and things just going haywire at runtime.

Yes, linker error is better than what undefined behavior, I guess. Yeah. Okay. And the last thing I wanted to mention was just that the CppCon YouTube channel has continually been updated over the past few weeks. They're up to 159 videos for the 2018 playlist, which sounds like close to everything, if not everything. And they also have 44 lightning talks, but

currently all lightning talks are marked private, so we can't actually watch them yet. Hmm, that's weird. That's a bummer. Yeah, I was really looking forward to watching them. I'm assuming they'll be up soon. And 44, I'm not sure if that's all lightning talks or if there's a couple more left to post, but it sounds like a sizable chunk of them. Yeah, and I think 159 is probably almost all of this here.

One of my talks from the last day of the conference just went live a couple days ago, too. So I think they're getting towards the end okay okay so ashley uh as we already mentioned a couple times you were at the san diego iso meeting and am i right that you spent most of your time at the library working group uh yes that is correct the library evolution Evolution Working Group specifically. Okay. Go ahead, Jason. Clarify, so there's Library Working Group, LEWG, I get lost in all of these different things, right? I do too. So I'm not sure there's actually anything named Library Working Group. There's Language Working Group, which is LWG, which does all of the wording for library features.

And the design of library features is handed in Library Evolution, a.k.a. LEWG. And then analogously for language, there's the Evolution Working Group, or EWG, which works on new language features. And then the core working group does the wording for the new language features. So the LEWG is like the first step in the pipeline to make sure things look good before it's sent off further down? Or is it the last? Which way does that go?

Papers go to LEWG for design approval before they go to LWG for wording, which is why one of the great pieces of advice in the how to write a good C++ proposal we were talking about earlier was that your R0 version doesn't need to have wording because LEWG doesn't care. Oh, okay. It's good to know. Yeah. So one of the things we should talk about is we mentioned it last week in our pre-trip report discussion that there are two new study groups. There's LEWGI and EWGI.

Could you talk a little bit about those? Yes. So this mailing had, I think, 60% more papers than any previous mailing. Like the largest mailing before the one for San Diego was much smaller. And in an effort to not let so many of those papers languish for meeting after meeting, they created these new incubator groups to give a lot of those new papers that probably aren't targeting C++20 some feedback a little sooner so that they can come back once we've finished all the work for C++20 and move their features then. So I didn't follow.

By the way, they are pronounced Loogie and Oogie officially. Of course they are. Bryce led Loogie and did a really great job. Loogie and Loog combined saw almost 100 papers last week, which is well above any previous record. So it will make the process longer for new papers if we continue to do it, but I think it'll make everyone's use of time more efficient. So it might not be the case that these groups meet every single ISO meeting? Like

the next meeting, if there aren't as many papers, they might not need to meet or they might not need to meet as long? It is unclear. These incubators were added pretty soon. Like, these incubators were added right before San Diego because everyone saw all the papers and said, we need to try something new

to see more of these papers. So I think the plan is to do them again in Kona, but I'm not sure. And I wouldn't be surprised if it changed at some point in the future. Goodness gracious. It's amazing just how much that you all are trying to deal with. So Lugie pre-processes them and then goes to where you spend most of your time into L LOOG. Now, just out of curiosity, since we have the pronunciations for those two things, is LWG,

does that have an official pronunciation as well? I don't believe so. I think LWG is just LWG. Okay. Marcel will correct me if I'm wrong, I'm sure. So since you spent most of your time Okay. Marshall will correct me if I'm wrong, I'm sure. Okay. So since you spent most of your time at Lug, what was the big news out of that group this meeting? Oh, there was a bunch of news out of that group this meeting.

The design review for ranges was already mostly complete, and then lwg spent most of their week doing the wording for that so ranges is merged into the standard for c++ 20 which people are very excited about um we also moved stood is constant evaluated to lwg we saw that in luge this week um this allows a program to determine whether it's being evaluated in a constexpr context or not, which is useful for various things where if you are trying to write portable code where sometimes something is constexpr and sometimes it's not based on what platform you're on, you can say if std is constant evaluated, do the compile time thing, otherwise fall back to this runtime

behavior. It's a little more nuanced than that because there's not actually a notion of compile time versus runtime, and I don't claim to understand all the details, but it's pretty cool. We're excited about it. That one, this is an interesting one to me since you brought it up, is constant evaluated. It's a library feature, but it's impossible, I'm assuming impossible to implement without a compiler hook. Correct. It is a library function call to get at a bunch of compiler magic. Okay.

So did L-E-W-G LOOG have to have to coordinate with EWG to make this happen? I don't remember if we coordinated with EWG specifically. I know there were implementers in the room when we discussed it and they, at least one implementer said they had an implementation of it that worked. You're like, good enough

for us. And the naive implementation is you always return false, and then you always do the runtime thing. Oh, that would be unfortunate. It would be unfortunate, but... But I guess... Profilers that don't want to spend the effort to put in this magic

or can't for whatever reason can always provide an implementation even if it is not necessarily the one you would want. Interesting. Okay. All right, thanks. So to step back a moment, you said kind of the big news was that ranges is moving forward. I don't think we've talked

about ranges in quite a while. What does the final merge proposal of ranges look like? I might need to claim not qualified to answer that question here. Well, I mean, I haven't looked at it, but it has to be huge. Like, add a considerable number of pages to the standard.

Oh, yes. I think the one ranges proposal that was merged was over 200 pages. Good gracious. So that's adding like 15% or 20% to the standard, something like that, if I have my numbers right. Yeah, it was a big undertaking. When the motion passed in plenary, we all stood up and applauded because it was such a large body of work.

I mean, it's been such a long time coming. We interviewed Eric Niebler shortly after he gave his C++ Now keynote in 2015 I believe Rob we had him on the first year of the show and I've been kind of waiting for it to get

merged so that I could know that it was going to actually end up in the standards so that's pretty cool it'll be in 20 and it looks like networking know that it was going to actually end up in the standard. So that's pretty cool. It will be in 20. Yeah. And it looks like networking is not going to make it. Yes, that was the other big thing out of LOOG this week is that there was consensus to delay networking until C++ 23. No one had done a full design review of the networking TS in several years.

And we like to think we've learned a lot about type design in the last several years. And basically the only way it was going to get in for 20 was if Luke met an additional time between San Diego and Kona and spent a week going through the entire proposal. And that felt like a lot of work to do. And we were likely to make some mistakes that would be hard to walk back later. So we decided we'd wait to see how executors and co-routines turned out and do networking for 23. Okay. So it's that, Yeah, that's also a considerably sized proposal, right? Hundreds of pages or something. I believe so. Okay. And since you just mentioned executors, which network depends on, I believe, it sounds like there is going to be some consensus on executors, at least going into the Kona meeting, right? Yes, there was consensus on part of the executor's proposal.

So it looks like we're going to hopefully end up adding the, quote, fire and forget interfaces into C++20. The APIs that allow you to wait for the result from a task put on an executor probably won't come until C++ 23, but we'll get something in for 20. And that also means that the extensible properties mechanism for executors will get in for 20, which is a brave new world for C++. What is a way to query at compile time what properties your type has. And so you can say things like require a non-blocking executor, require a, or the non-blocking is the one I'm thinking of at the moment. And then you're sort of able to like swap out implementations. I got

real lost in all these discussions. I'm not going to lie to you. It looks pretty cool, though. You can swap out implementations without having an abstract executor type that you're passing around everywhere, which is kind of cool, because then different what would otherwise be subclasses can have different APIs, and you can ask, like, what APIs do I have accessible to me right now? Okay. So it's interesting. It's new. Yeah. I feel like I would also get lost on that. Um, so when you're sitting in Lug, um, are you exposed to everything that they're talking

about or do you ever break up into like smaller groups to talk about a specific thing? In San Diego, we did not break up into smaller groups at all. At my first meeting in Jacksonville, we did. But it's not always particularly helpful to break up into small groups because you ultimately have to bring the entire discussion back to the large group to vote on it anyway. So he didn't do that this year and managed to get through a fair number of papers. So sitting in a room for however many, you know, they always tell us like 10 hours a day, but we know it's actually like three hours a day and the rest of the time you're like drinking beer and hanging out on the beach, right? No. hours a day and the rest of the time you're like drinking beer and hanging out on the beach right no but i mean doing that for five days straight and being like so many things it's going to be very difficult to keep everything straight in your head what you're working on yes i was very

tired by day two or three and then there were two and a half more days. So it's exhausting to try to keep up with everything that's being discussed. It's very easy to have a large sense of imposter syndrome at these meetings. I can't even imagine, yeah. And if you don't mind, as an aside, before we continue on with, like, what specifically did make it through, Lug, I'm having a hard time convincing myself to pronounce it. Um, what was your specific interest and like what the papers that you've worked on, like, what are the things that you're focusing on while you're sitting in this meeting, listening to everything going on?

Um, I'm generally trying to look at how, like, is this the API we actually want? One of the things Abseil does a lot of before we open source any new libraries that Google's been using for the last 19 or 20 years is make sure, hey, this library probably grew like a weed and not like a painting. Let's make sure this is the actual thing we want to release before we put it out into the world. And so that's generally the lens I'm looking at things from, since it's the thing I have the most experience with. There are various other people that are on the lookout for, hey, we can't actually do this because this will break ABI and all of the compilers, and that is a non-starter for most things. There are other people looking at various efficiencies for how fast should running time of this thing be and things like that. I can see that being really interesting conversation.

If one of you is basically like, we need this, it's a beautiful API, and the compiler implementers are like, I don't care if it's a beautiful API, it's impossible to implement. If the implementers say it's impossible to implement, it is very difficult to get a paper moved forward. I would believe that, yeah. At some point I'm going to have to attend one of these, I think. Okay, thank you for that. And then as we move forward, yeah, we'll keep that in mind.

And I'm we move forward, yeah, we'll keep that in mind. Yeah. And I'm curious to know, since you say your kind of role is putting a critical eye on some of these APIs before they go into the standard library, would you mind saying, you know, what are some of the things that you've given your feedback on and tried to change? I know that coroutines has kind of been looked at by Google. Isn't there the core coroutine proposal to change the way that's going to work? Yes, there is. That's all on the language side, though, and I have had no involvement in that whatsoever.

One of the proposals I wrote for this meeting was actually a fairly short paper on the shift left and shift right algorithms for ranges because at some point Titus Winters who is really on my team at Google he had a note written away somewhere like hey we need to look at how negative counts are handled in these algorithms and I don't remember what the rest of that was but go investigate and I said cool thanks and it turns out that the original paper adding these algorithms, which are great algorithms that we totally need to have for ranges, defined shifting by a negative count as shifting by zero, which seems like a great way to hide bugs from users, because I don't think any of us would expect to get shift by zero if we asked to shift left by a negative number.

Yeah. So I wrote a paper saying, hey, let's make sure this is the behavior of this API that we want. And I contacted the original authors about it, and they said, oh, yeah, we didn't think about sanitizers being able to warn on this if it was actually undefined rather than defined to shift by zero. So that actually went through this week too, which was exciting. That's cool. Yeah. Did you have any, you said you've, I think you said you worked on three papers were all three of them at this

meeting? No, I am the author of the infamous string view proposal from Jacksonville that started a 300 email thread on the reflectors. So my bad, but this is the string view. No way from Jacksonville.

So wait, what is that one about done? Um, so the string view type has a constructor from const car star. It is undefined behavior to put a null pointer in that constructor. The Google type that this type was based on has always allowed construction from null pointer. And so I was proposing that we also allow the standards string view constructor from const char star to allow null pointer and construct the same object as the default constructor and an empty string i'm guessing uh yes okay and did that get accepted l e w g or

luge was fine with it um there was definitely it was not you know 100 yeah of course let's do this thing but the consensus was to move it forward And then there was a lot of discussion on email reflectors and in Rapperswil, which I did not attend. There was a joint session between EWG and LOOG about sort of the larger question of changing or there was a there was discussion on the larger question of defining previously undefined behavior because that sounds like a thing you should be allowed to do yeah and i think the consensus from that discussion is yes this is sometimes a thing you're allowed to do but you can't do this so we gave up sometimes you're allowed to but you're not allowed to at this moment. I tried. Oh, well. Okay, well, that's something I'll have to keep in mind. I did not realize that that's undefined behavior.

Yeah. And some compilers just construct the one, construct the default string view. If you pass that constructor a null pointer and some of them crash, and who knows what the one we're using does. I could imagine some of them just try to run strlen on whatever's passed to you or something. Yes, and that's why it's undefined as many implementations anyway run strlen, which is also not defined for null pointers.

But you can imagine if you're already doing an O of N operation, it's actually not that much more expensive to just stick a, is this null, length is zero, if not run Sterling. Yeah, I know that I'm very bad with my big O algorithm analysis, but I'm pretty sure big O of N plus one is still just big O of N, basically. Yep. Okay. Interesting. And a little disappointing that that didn't get through. Feel free to arrive my paper if you want to fight my battles for me, but I've given up.

Okay. Well, then maybe perhaps this is a bit too personal, but maybe I'll ask anyhow. Do you wish that you had been able to attend Rapper's Will so that you could have presented your viewpoint in person? Honestly, no. Stringview as a type is now anxiety-inducing for me after that whole debacle. We'll stop discussing Stringview then. And I was perfectly content for my colleagues to have this discussion on my behalf. Okay, I do have to ask one other question. Since you work on Abseil, and Abseil is kind of this drop-in replacement

when you can be for the standard library things that you don't yet have in the standard library, did you have to do anything to the string view in Abseil to match the behavior of the standard library? We haven't yet. That's still a question we're trying to figure out because we probably can't safely migrate our entire code base to use StdStringView given that we've always allowed construction from null pointer and we have 250 million lines of C plus plus code, all of which uses string view. Right? Uh,

so we are not sure what we're going to do about this yet. Interesting. I like to interrupt the discussion for just a moment to bring you a word from our sponsors. Authors of the PVS studioalyzer suggest downloading and trying the demo version of the product. Link to the distribution package is in the description of this podcast episode. You might not even be aware of the large number of errors and potential vulnerabilities that the PVS Studio Analyzer is able to detect. A good example is the detection of errors that

are classed as CWB14, according to the Common Weakness error type, for example, in one of the latest articles, We Check the Android Source Code by PVS Studio, or Nothing is Perfect. Link to this article is also in the description of this episode. PVS Studio works in Windows, Linux, and macOS environments. The tool supports the analysis of C, C++, and C Sharp code, and Java support is coming soon. Try it today. Okay, so I guess going back to some of the news that's coming out of the San Diego meeting,

let's talk about what else went through LOOG to LWG. I think we've talked before about the text formatting library? Yes. We forwarded the text formatting library, which is actually pretty cool. It actually uses information from the type system to determine what type you're trying to format instead of printf style specifiers where you have to specify again what type your type is and it has support for argument reordering which makes doing things like formatting sentences that are translated in multiple languages much easier because

argument order that would be say zero one and one sentence could be one zero and another sentence in a different language so So that's pretty cool. There's an extension mechanism so that users can specify how their own types should be formatted. So if you've written some really complicated type and you want to be able to specify like, this is the canonical way my type should be printed, you can write this extent. I forget exactly how the extension mechanism works, but there's a way you can hook your type into this formatting system. The lecture that I mentioned at the beginning of the talk, Rob, I actually was largely focused on the string formatting library. The title of the talk was rethinking. Actually, what was the title of the talk?

Oh, shoot. Moving beyond standard out. actually, what was the title of the talk? Oh, shoot. It's been that many days, Jason. Moving Beyond Standard Out. That's what it was titled. Yes. So I was really interested to know if this got accepted and disappointed that I couldn't get that information until after I had given the talk. So I'm glad it was accepted.

But there's a couple questions that I had, and I don't know if the thing that's currently available, is that effectively what got accepted into LWG? Do you know, Ashley? I can't remember if there was any feedback we gave. I think the only feedback we gave to the author, we largely said forward this to LWG for C plus plus 20. I think I suggested the author also look into an alternate extension mechanism for user defined types. Um, I think I don't,

I think we suggested some sort of ADL based mechanism or at least investigate if that would work rather than, I think the thing they had now is a little more complicated. Okay. Imagine saying anything's more complicated than ADL. Right. I was just thinking that's a little surprising because I've heard, you know, well-respected people say they wish they could remove ADL from the language. I'm also one of those people, but there are certain cases in which it is useful.

And the extension mechanism they're trying to do is really one of the things that ADL is good for rather than all of the things it is not good for. Okay, that's cool. The proposal was forwarded to LWG without any significant changes requested. Well, that's excellent. Hopefully everything continues to move forward with it. So Stacktrace library was forwarded on as well? Yes. There's really not much to report here. The Stacktrace library, I think, is based on Boost.stacktrace, which has been around for a while and is used by a lot of people.

And what's nice here is you get more debugging information when your program crashes. It will actually give you a stacktr trace of where it thinks your program crashed rather than just you aborted trying to dereference this thing. Good luck finding it. So I have never actually used one of these stack trace libraries. At any point, can you just say, hey, I would like a call stack now, and the runtime has to give you something?

I believe that is how it works. It is not efficient, so you probably don't want to go around asking for stack traces all over the place if you want your code to be reasonably fast. But the idea is if you are in some sort of error handler, you could capture a backtrace at that point and it would tell you roughly where the problem might have actually been right and you keep saying roughly and approximately i'm guessing because the optimizer probably might have done whatever presumably also i am not confident in my knowledge of most of these proposals because there are a lot of them and written by people who are much smarter than me. Okay. Okay. We already talked about is constant evaluated, right?

Yes. Okay. Removing stood span operator equal? What was that about? There was an argument over the meaning of span. There were several arguments about span at this meeting. There's also an argument about what signedness the return type of size and span would be that I believe the entire evening session on. The resolution of that, if anyone is curious, the return type of size in span will be unsigned, but we are adding a std s size that you can pass things to,

and it will return you a signed version of the size. So that was the compromise we landed with there. But the problem with spans operator equal is that some people wanted span to be a regular type. And if you've been following the concept discussions, regular is a particular concept that describes the nature of a type. But if you're trying to propagate constaness in something like span, you can't be regular and also have shallow copy and deep compare. I'm not going to claim to understand all the technical reasons for this, but this is what the talk I heard on the topic says. And so you can basically either make it shallow compare instead of deep compare, meaning that you do the operator equal compares

what things point at rather than the underlying data, or you can make the type semi-regular and drop the operator equal entirely. And we took the latter approach with span. Okay. And as you said, span has had so many arguments around it. I'm curious if there's anything that you want to call out from your lens of wanting to make good APIs? Is span moving in the right direction? I think span is a little confused about what type it's trying to be in the same way string view is a little confused about what type it's trying to be. There's a lot of confusion, or at least there seems to be at this meeting,

about whether a span is a container or a view. And similarly, people can't decide whether string view is a continuous sequence of characters or a pointer and a length. And so depending on which side of these arguments you're on can dictate how you want the API of the type to behave. All right. I have to ask, how is a contiguous sequence of characters different from a pointer and a length? I don't know. Okay. I cannot like, when you said that,

I'm like, I cannot think of anything that makes these two things different because they both imply contiguous memory. I think where it comes into a problem with string view is if you have an empty sequence of characters that is not necessarily analogous to a null pointer. Okay. So coming back to the paper I wrote that was problematic. Right. Null pointers make everything awful. We should all just program in Java.

Just kidding. We know you don't mean that. No, I don't mean that i actually don't know any java at all so that would be a terrible suggestion well someone said that basically null pointer was the billion dollar mistake and computer science or something like that i don't remember who said that now but it was some famous computer scientist at some point. Well, but so what is the conclusion? Is span a view? Does span give us mutable accessors? Does it assume contiguous memory? So if you have a span over a constant type, you, I believe, are not able to mutate the thing you are viewing over. Okay. I think we've settled on span as a view, not a container.

Okay. There are probably people on the committee that still disagree with me on this point. But I believe we decided that span is a view and that if you have a view over a constant thing, you should not be able to mutate the constant thing. I don't remember if you have a span over just a type T that's not const, if you can mutate it or not. I don't remember where we landed on that. That part of the API was decided long before I showed up. And you said constant propagation comes up with some of these conversations. Did you say that or did I imagine it? No, I said that.

Okay. I'm just thinking about this argument or discussion around shared pointer and unique pointer, how you can have a const reference to a shared pointer, but you can still mutate the underlying data. And that's where part of this const propagation kind of question comes up as well right and there's a i think it's at least somewhat similar to the const problem with stood function where if you have a const overload and a non-const overload it like always prefers the non-const overload and allows you to like modify things that should be const, which is not true. Right. There was a proposal to try to add a new function type to fix that, too, which was also cool. Did that move forward? Not officially, because we looked at it on Saturday, and you can't officially move things that you look at on Saturday because you're not technically in session.

But I suspect it will be sort of, we will have to decide on a name and then move it along in Kona because we did name runoff voting on Saturday, which was a very bad idea. You should not let Luke do naming on Saturday because I believe one of the types with the most votes was stood mo function. Yeah, okay. votes was stood mo function. Yeah. Okay. So Lug will need to look at it again,

but hopefully not for very long. So you just said Saturday, you can't actually, you're not actually in session, but it sounds like everyone was there regardless. Yeah. Pretty much all the rooms continued meeting and doing work until they either didn't have quorum or everybody fell

over. So is it actually fun going to the standards meetings? Parts of it are fun. It's also extremely exhausting. Okay. And you just got back what, on Monday or Sunday or something? Sunday morning.

So I figure if I were to do something like this, I'd probably be, my brain would be mushed for at least a week afterward. Yeah, I caught a cold on the flight back, so I've been half sleeping, half attempting to work from my couch for the last, what, three days now. Yeah, that's easy to believe. It sounds like a conference, but worse, as far as that kind of exhaustion goes. Yeah, having been to both CPPCon and now the Standards Committee meetings, it is probably worse than CPPCon and other conferences in that aspect. Because you have to do a lot more thinking. You can't just sit there and passively listen to the speaker. You actually have to pay attention or you're not being very useful. Yeah, they call for a vote and you're like,

huh, what? Sure, yes. Ideally, if you have not been paying attention or don't understand what's going on, you do not raise your hand. However, we cannot bar anybody from voting if they are in the room. But if you don't know what's going on, you really shouldn't vote

or at least the chair of LOOG will get very angry at you. They don't know how other rooms operate. Who was the chair, by the way? Titus Winters is the chair of LOOG. Oh, okay. Okay. So another thing you worked on in LOOG, I believe, was going to make Jason very happy, more constexpr and standard library?

Yes. So now we can allocate memory and do work in constructors and constexpr. So that opens up a much wider range of library types that you can make constexpr. I know we forwarded a paper on constexpr containers and a constexpr bit set. And we saw a paper on making more math functions constexpr. And actually we saw it right after we forwarded is constant evaluated. And we told the people that wrote the math paper, hey, you have it's constant evaluated now.

You can make even more things constexpr. So go make more things constexpr and come back to us at Kona. Excellent. I think I saw previews of several of those papers that you mentioned from the people who are working on them. Interestingly, people tend to forward constexpr things to me these days.

I'm definitely looking forward to all those. But I have to ask, what do we do about – since you're looking at it from the library lens, but if you can – or maybe is this something we should save for later? I don't know. But you said that you can do allocation in the constructor. You can do memory allocation. Mm-hmm. But we still don't have constexpr destructors, right?

I don't know. Okay. So we can, but like new has now become constexpr. Is that what you're saying? I think so. This was discussed during the constexpr container discussion. Okay. So I think the paper that allowed allocating memory in constexpr had gone through at some previous time. Because I was not in the room when we discussed making that constexpr, but I guess you can allocate memory in constexpr now.

Wow, that's pretty crazy. Oh, I see. I see what I missed. Okay, std allocator has constexpr methods allocate, deallocate, and destruct. Okay, so std allocator itself is becoming constexpr, which makes sense from the library perspective. Because from your perspective, you're like, whatever. Allow those to be constexpr. I mean, in all seriousness, why not allow them to be constexpr?

It's still up to whether or not the language will let you do anything useful. Exactly. Sure. Okay. And you could do fixed size allocators and whatever. That's good. I like to hear that. So then the next obvious thing is, did you make changes to or approve changes to any of the standard containers for more constexpr-ness? Yes. What was in this container paper?

I don't remember seeing the container paper at all. Do, do, do. I don't remember seeing the container paper at all. Do-do-do-do. We can edit out any pause in here. Yeah, that's fine. I'm just trying to remember what was in this paper. I'm looking it up. Okay. Oh, so the standard containers and constexpr paper enables constexpr destructors.

Oh, okay. And along with the changes that allow constexpr allocation and constexpr in-place construction, this gets you most of the containers, it looks like. Okay, and so you all approved that through LOOG. Mm-hmm. So there's a very good chance we'll have pretty much the ability to do anything we want to in C++20. I'm on board with that. But yes, I'm really honestly very glad that the things like more constexpr math that you pushed that you let those go through and like the containers like the containers are cool but the

rest of the things like being able to do constexpr like cosine yeah like that's that's real that's stuff that i can see immediate uses for the uh the constexpr allocation that all has workarounds because you can just do, well, you know what, I'll just do like a std array of like a billion objects or something and let the compiler sort out the difference, right? But yeah, good. Very cool. Okay, I think we might be running out of stuff to go over. Is there anything we haven't brought up yet, Ashley? The only other interesting discussion that I recall off the top of my head still in a post-WG21 haze is explicit constructors. So Lug and LWG do not agree on the policy around explicit constructors right now, so that will be

an interesting space to watch in future standards meetings. LWG's policy, if I understand it correctly, is to only make single parameter constructors explicit. So even if you have a constructor that has one explicit argument and then a bunch of potentially defaulted arguments, they would not make that second constructor explicit because they seem to be leaning towards providing delegating constructors so that the multi-argument ones don't have to be explicit. But LEWG voted in San Diego because there was a paper to this effect and did not have consensus for applying explicit only to single argument constructors because of the concerns that implicit multi-argument constructors, especially if they have default arguments, allow you to

accidentally invoke implicit conversions and end up with the wrong thing at the end. So I expect that there will be more discussion on this going forward. If I get my vote, I'm in favor of as many constructors being explicit as possible basically that would be titus's position as well he actually gave a talk about almost always explicit he's been giving so many talks recently i'm sorry titus i don't remember which conference you gave that talk at um but so lwg and lewG have some soul searching to do on this matter. That's, that's interesting.

And it leads me to a question. Like one of the things that has been just a constant thorn for me in my own code and in teaching is the constructors from like a non-const to a const shared pointer not being explicit. And I'm guessing that you can't go back and make some of these things explicit like shared pointer constructors. It's unclear. Yes, technically that's a breaking change,

and generally speaking we don't like making those because then users yell at us. But the library implementers in the room, and we were discussing this paper didn't seem to think that that would actually be a huge problem in practice. Because if you're getting the implicit conversion right now, your code probably isn't doing what you want anyway. Right. And so turning on the explicit constructors in cases like that, like, yes, some people who are probably dealing with code that isn't behaving as they expect will get problems as a result,

but it'll make everything else so much better that it might not actually be a big deal in practice. Okay. Well, let's see if we actually see that happen. Maybe I should submit my first paper. There you go. We're going to drag you on board with us. Okay. Well, it's been great having you on the show today, Ashley. Where can people find you online? I do not have much of an online public

presence. AbSale's website is absale.io and go look at include CBP instead of looking for me. That's a good one. Okay. Thank you so much. Thank you. 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.com. Theme music for this episode was provided by podcastthemes.com.