CppCast - Rapperswil Trip Report

Episode Date: June 15, 2018

Rob and Jason discuss the Rapperswil trip report and other C++ news. News What's next for Visual Studio Visual Studio Roadmap Build the future of the web with WebAssembly and more (Google I/O '18) WebAssembly Physics and DOM objects "Core Coroutines" proposal Microsoft Buys GitHub: The Linux Foundation's Reaction Links @robwirving @lefticus Sponsors Backtrace Patreon CppCast Patreon Listener Survey CppCast Listener Survey

Episode 154 of CppCast recorded June 11th, 2018. In this episode, Jason and I discuss some Visual Studio and WebAssembly news. Then we talk about the Wrappersville ISO C++ developers. I'm your host, Rob Irving. Joined by my co-host, Jason Turner. Jason, how are you doing today? I am all right, Rob. You know, we keep saying the only podcast for cds plus developers are we just going to leave that in there indefinitely i think you know we

talked to john and phil and they they said that they'll they're fine with us sticking with it and they'll call yeah they will the other only podcast or something like that yeah right yeah we could say the original or the favorite or oh that's a little mean to call ourselves the favorite i think that's meaner than saying the only yeah we'll have to think more about changing it to the original that might work yeah yeah well whatever yeah well at the top of our episode i'd like to read a piece of feedback uh this week we got a tweet from todd saying nice episode on vc package interested in doing an episode on spack pm and you know we've talked about vc package a couple times obviously last week's episode on it and we've talked about conan several times i have not heard of SPAC. Have you, Jason?

I have not heard of SPAC at all. And in fact, I am attempting to look it up right now. Their website is SPAC.io. Okay. It says it's a flexible package manager that supports multiple versions, configurations, platforms, and compilers. Python, R, C, C++, or Fortran. Oh, it's not just C++ Oh, interesting, okay

Yeah, that is interesting Yeah, we'll have to look into this one a little bit more and maybe we will try to get them on the show Yeah, could be interesting Well, we'd love to hear your thoughts about the show as well You can always reach out to us on Facebook, Twitter twitter or email us at feedback at cpcast.com and don't forget to leave us a review on itunes so uh we were going to have a guest on today who was at the rapper swill iso c++ meeting unfortunately uh he was feeling a little under the weather and couldn't make it.

But we wanted to make sure we got an episode this week. So we have a couple of news articles to discuss, but we also have this very thorough trip report on Reddit, C++, from Bryce Lallback and also Nevin Lieber, I think, worked on this. And a third person who I don't recognize. Uh, so yeah, we will go over some news and, uh, we'll talk about this report. I'm sorry. We don't have a guest who is there to talk about it with us, but, uh, yeah, it should be an interesting conversation. I hope. And we'll see what happens.

It might be a little bit short episodes. We'll just have to fill it with random things like I am right now. Okay. be a little bit short episodes we'll just have to fill it with random things like i am right now okay well uh the first thing i have is uh a post on the visual studio blog and uh there's not too much meat in this article but it's basically saying the next visual studio version will be visual studio 2019 uh which makes sense i think we would have heard about it by now if they were going to do a 2018 release. So yeah, the next big version will probably be like summer or fall next year. They're not putting down an actual date yet. They're not really saying a whole lot about the release in general. Although the one thing that i found to be really interesting was they linked to this other website where you can see on the visual studio roadmap and currently the roadmap is just

referencing uh you know 2018 q2 and q3 which will still be the 2017 release. But I wasn't aware that they gave us this much information ahead of time before. And just to highlight some of the things that are in this roadmap for the rest of this year, 2018 Q3, for C++, they have one feature labeled See Just My Code in the debugger in C++, and Use Step Back in the debugger in C++, and use step back in the debugger for C++. So the step back part, I'm not sure if that's like full reverse debugging

or if it's just, I don't know, kind of a lighter version of that, but it sounds cool. Yeah, I'm not sure about either one of those, but I think I saw something, like i think i saw some preview of this step backward in the debugger reverse debugging stuff for c++ in a recently released but i could be misremembering something also well that one says q3 so i don't think it would be out yet unless you were looking at a preview yeah i might have been looking at a preview of the next release of visual studio you know it's interesting, this upcoming Visual Studio 2019,

in a way, like, I don't know how to say this without sounding like I'm trying to be rude or anything, but in a way, I don't care, but I will clarify, and that is because they have been making such good updates to 2017. Every quarter, we're getting significant updates to the c++ stuff in my mind that could have just continued indefinitely like why do why do we need a whole new visual studio release but you know they have their plans yeah i also wanted to point out that they say on here that like you might start noticing all of the commits that we're doing to github leading up to this release, basically.

Yeah, so in addition to just looking at that roadmap, you can actually just stalk them on GitHub and see what they're up to, which is kind of cool. Yeah. So the next thing I have, and this was like a month ago, actually, but it just was reposted on SQL subreddit. And I saw it. And this is from Google IO, which had their conference last year. And I've never been to IO. But I'd imagine most of the content at IO is kind of focused on Android and focused on

web development, JavaScript and stuff like that. But they did a session called Build the Future of the Web with WebAssembly. And I thought it was a really great session. We talked about WebAssembly a while back with JF Bastion. And Google is highlighting kind of the current state of WebAssembly. And they showed some demos of actual companies making products on the web using WebAssembly which I thought was really cool and these are like real deal applications like AutoCAD which has been a really powerful desktop application for years has you know ported the app onto web assembly and they had a really interesting story because they talked about how they had kind of tried doing a web

version of autocad a couple times and they like first tried it with flash and that didn't really go too far and and then they tried making like a you know full port in pure JavaScript. And they kind of got a basic viewer and realized, hey, we're going to have to rewrite a ton of code from C++ to JavaScript if we want to do this. And it's going to take forever and be really unperformant. So now they have WebAssembly. And it's a really great story. And the application looks fantastic. I've heard that WebAssembly is like just maybe 20...

No, what's the word I'm looking for? It's like 75% the speed of native or something like that. It's pretty darn close to native or better than that. For a web application, that's huge compared to JavaScript performance out of math. Yeah, well, yeah. Although the JavaScript interpreters these days And for a web application, that's huge compared to JavaScript performance out of Amazon. Yeah, although the JavaScript interpreters these days are just insane. I mean, we've had other guests on that have talked about this, like how WebAssembly or Asm.js and taking advantage of the optimizing compiler that C++ has and just being able to execute much more dense code as itself, much faster than native JavaScript in many cases.

Yeah. And I thought it was really interesting how the other application they showed was able to mix WebAssembly with JavaScript. I think they said some parts of their ui was react js i'm not too familiar with that but i guess i hear a lot on twitter um but it was react jsu i and then you had like i think it was a like a design tool and then you had a work surface which was all in web assembly and that wasn't even like a port of an application that was a completely new application that they or maybe it was it was a port of a mac

application but but anyway it was uh another really impressive piece of work with web assembly it's an interesting world we're entering into here yeah and if you're interested in learning a little more obviously i recommend watching the talk but they also put out this link to where you can see a kind of quick demo of WebAssembly in action with this hourglass thing that's, I guess, using actual physics to calculate the, you know, granules of sand going down the hourglass. It was kind of cool. Huh. Yeah, that is pretty neat yeah okay next one um and this was posted a couple days ago i'm not sure if this was i guess it was presented at uh rapper's will but this is a paper called corco routines i didn't really see this referenced in

the um the mainstream report paper we're going to discuss have you uh no i don't think so yeah but anyway the this paper is titled core coroutines making coroutines simpler faster and more general and you know i i'm not sure how i feel about this one i mean coroutines they're supposed to make it into C++20. And I guess this paper is trying to change the syntax and change a couple things about how coroutines would work. I'll be honest, I don't like their alternative syntax. You don't like the arrow operators everywhere kind of thing? Yeah, so they're saying instead of co-await it would replace it with

uh square back square brackets with an arrow in it and i don't know i like i wish it was just a wait but i like co-await more than these brackets i think well yeah and a wait they risk that being too conflicting with existing code co-await will probably conflict with some existing code. Spelling it this, as they put it, spelling it this way with this operator, yeah, it probably has very little overlap with existing things. And it's like, it's weird to see this operator overload

and partially down halfway through the paper. So that's like operator open square bracket less than minus closed square bracket you're like yeah but i don't know i i haven't spent any time with co-routines yet to feel like i have an opinion strongly on this but i know we've heard bjarne say in the past that like anytime a new feature gets added to the language people want the syntax to be really verbose because it's a new thing and then after a couple of years of using it everyone's looking away for a way to have the the syntax more terse so it's an interesting at least let's you know the idea of can we jump out of the gate with this more terse syntax. And, I mean, we see this happening with concepts over and over again, too. Yeah.

I don't know. I just feel like I'm fine with Co-O-Weight. I haven't used it much, so I wouldn't say I have a strong opinion. But, I don't know. I just like a simple keyword more than these extra characters. I don't know. Well, okay, let's clarify. You say you haven't used it much.

No. Have you used coroutines? No. I mean, I'm familiar with the await syntax from other languages, and maybe that's why I also like co-await, because it's more familiar to me from seeing it in other languages. Right. Which is maybe a reason to stick with that

so that someone coming from another language like c sharp and c++ would kind of recognize the keyword that kind of functions the same way yeah but this does have an interesting kind of syntax it's like oh well this thing yields a value to this thing which yields a value to this thing, which yields a value to this thing. I mean, it kind of looks like a thing. Okay, next one. And this is not really C++ related, but it's kind of interesting in general to most programmers, I think. I saw a lot of people talking about it on the internet last week. Microsoft bought GitHub.

Yes. Yeah. a lot of people talking about it on the internet last week um microsoft bought github yes yeah um and the article i have here is actually uh the linux foundation's response to that news and i i know there there seemed to be some people who were kind of freaking out over microsoft buying github i saw there was some news about you know git lab and alternative getting a lot of traffic of people moving their repositories and i actually use git lab too and it's a perfectly good tool but i think the people who are freaking out are uh and wanting to move from github to gitLab are jumping the gun a little bit. I don't really think that's necessary.

And it seems that the Linux Foundation is basically saying that they agree, that they think this is a good move and they're not really worried about Microsoft doing anything bad with people's source code or anything like that. And I feel like a little bit of competition is never bad. So in a way, this is,

for the people who are jumping ship to GitLab or to other services, at least it's giving a shot in the arm to the other services, which will help them compete a little bit more and keep everyone on their toes. Yeah, absolutely. But yeah. Yeah, I think Microsoft has good intentions. I mean, they've done so much open source work

over the past few years you know if this happened like 10 years ago people might be more uh valid in their concern but uh microsoft has i think earned a lot of goodwill from the open source community lately yeah a lot of their projects are like typescript almost completely open source i believe and yeah yeah okay so uh we want to talk more about the wrapper swill iso c++ meeting as we said obviously we weren't there but uh we have a nice trip report to look at and it looks like the biggest uh new item that happened last week was contracts made it into the c++20 draft? Yeah, that's fascinating to me because I thought from the last hypothetical roadmap

that we saw that we didn't expect contracts to necessarily end up until 23, or at least I thought it said that 20 was an optimistic goal and 23 was the realistic goal. Maybe I'm reading, I remembering that backward, but either way it's in. Yeah.

And I'm actually interesting. The paper that was linked to hasn't been updated since 2016. Yeah, that is interesting. I wonder what changed to get it in if the paper is the same. Maybe it was just enough community consensus that it was necessary. So have you spent any time looking at contracts?

I did spend some time looking at the paper. I'm not sure if it's something I'm going to use, but it certainly looks like it would be very helpful for library developers. I became convinced to train... my schedule's been busy. The last training that I did, the students there,

very concerned about code quality and security of code. And it seems they would be very interested in this and as i uh started thinking about it and talking about it with them like i became convinced that this is probably the main thing that's going to affect real c plus like i say real c plus plus developers the you know nominative c plus plus developer around the world because you can can specify, like, okay, this function expects a value that's less than two, and at the end of it, it guarantees, let's see, expects, what's the other keyword?

Ensures that whatever the state is of something will still be true at the end. And these, you know, it's going to be up to the compilers, I think, to what the various different ways are that they can be compiled and enforcement for them. There we go, three levels of contracts, default, audit, and axiom. But it may or may not add runtime overhead, and I don't know. I think it's a good add-in to the language, personally.

I'm glad to see that we've got it in. What is that default axiom in audit? Okay, so that's whether there's runtime checking or audit means this check is expensive. Do you know more about that? I do not. Okay. But you can control what is checked

and what is done in response to a violation. Yeah, so if I remember correctly here... Oh, it's saying... Yeah, go ahead. Go ahead. It's saying, default, the cost of runtime checking is assumed to be small, or at least not expensive. Audit, a check that is more comprehensive than default,

the cost of runtime checking is assumed to be large compared to executing the function. And axiom is a formal comment for humans and static analyzers. There's no runtime cost because the predicate is not evaluated at runtime. And then when you compile, you have three different options. You can say that your contracts are off, so it adds no runtime overhead at all. Default says the contracts are checked, and audit says default and audit contracts are checked. Okay, so maybe something you might want to do

is have a debug version where you're going to have all your checks in place and hope that your QA team would run into anything. Right, yeah, so default would build an audit mode saying all checks are executed regardless of the cost, and then your release build might be built in default mode that says only the non-expensive ones are checked at runtime. Or if you had, like, you know like you know you're saying no i need super

performance but i need to make sure that my ci does the right thing then your continuous integration build in default mode and then in your release build with them disabled or something like that but either way it's more code documentation and hypothetically information that the compiler can optimize around okay right i mean hypothetically i don't believe that's any kind of a guarantee in here but if you say in my contract this value is never going to be greater than four or less than zero then perhaps the compiler could emit different code in those cases right right hypothetically and correct me if i'm wrong but it looks like if any of these conditions are not met you just get an immediate program termination it should be the same as an assert i believe okay okay let's see uh you can do uh you can

also have a violation handler it looks like i like. I definitely need to spend more time looking at this. But more ways to document our code and more ways to put guarantees about what our code is doing. I'm cool with that. Definitely a good thing. Okay, next. The next item is standard library concepts. So I guess we already have concepts going in for C++20. So this paper

is to make sure the standard library is implemented with them. Yeah, that sounds right. Because I know concepts had to be done in multiple stages, they had to get approved first, and then the standard library had to be applied to them. And then when then they're going to talk about more terse syntax and those kinds of things right and we're still waiting to see if any of the terse or syntaxes go in or not i believe yeah at this point i think i'll be surprised if that makes it into c++ 20 but who knows okay uh did you read about this one much? The class non-type template parameters? Ah, that is at the top of my to-do list to make sure I fully understand what's going on in here. But I mean, currently a template parameter can be, um, uh, any primitive thing. It can be a bool, an int or a size T or whatever, um, or a type. And I believe the main point of this is just to extend it so that instead of just primitive things it can be anything that meets certain requirements here

must be equality comparable which relies on our spaceship operator must have us basically a spaceship operator let's see all of their bases and non-static data members recursively have a non-user-provided operator spaceship returning a type that is implicitly convertible and contain no references. Yeah. Okay. I wanted to interrupt this discussion for just a moment

to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more.

This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Bactrace to modernize across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. Okay, and the next one that they're adding to C++20 is going to be feature test macros. And, yeah.

I want that. Yeah, so this is just going to be you can add some macro to say, you know, I have SFINAE or something like that. So if you want to block off some code to use SFINAE or use some other, like, older piece of code, then you can do that. And this is another one, which seems like it'd be great for a library developers who've been waiting to move their users to a new version.

Now you could just use macros and then start moving your code forward. Right? Yeah. And GCC and clang have supported this pre standardization of it for a while. So in Chai script, like I wrote some code that was like, well, if, um, uh, standardization of it for a while so in chai script like i wrote some code that was like well if um uh deduction guides are supported then do this otherwise do this old thing

basically right and actually that's not quite right but whatever close enough um for the sake of this discussion it's close enough and uh i i go to test the code and it's not compiling on visual studio and i cannot figure out why not and then i have to go and research and visual studio was not going to officially support it until it was in the standard so in visual studio i had to do something that's like if visual studio and the compiler version is greater than this, then do this, otherwise test the feature macro. So, yes, I am happy to see the feature testing macros be official now. It does come up in the real code.

Yeah, it's one of those ones that I'm surprised wasn't in there earlier. I don't know what the holdup was, honestly, on it, but I'm glad to see that it made it through. Yeah. Okay, conditional explicit uh i'm not sure if i understand this one do you understand this one jason i do okay i think understand it yes all right um i'm going to double check yeah that's what i thought

okay so right now a function can be conditionally noexcept. Okay, you can say noexcept at the end of the function declaration and put in parens some compile time constant expression that would determine whether or not that function should be noexcept. With conditional explicit up at the front of like your conversion operator or your single parameter constructor or whatever you can say explicit as most things should be explicit that are that are otherwise add an implicit conversion and have in there some boolean condition that checks at compile time whether or not that explicit is true there i honestly i don't know why it's necessary because i don't know why like i don't fully understand why some things are conditionally explicit in the standard currently and you can find them in pair tuple and variant and optional specifically. All of those types have conditionally explicit constructors. But I don't see the reason for it.

I don't see the reason for conditionally explicit. I'm just like, make everything explicit. Explicit should be our default. I'm tired of implicit conversions. And it's another syntax thing for me to have to teach. Yeah. Okay. versions and it's another syntax thing for me to have to teach yeah okay uh so we have a couple other things that are added these ones seems like there might not be as much to talk about um oh come on the next one's awesome okay virtual calls and constant expressions yes virtual calls and constant expressions

virtual functions can be constexpr now. Oh yeah. That is awesome. This is, this is fascinating. I'm, I, I've thought for a long time that final methods should be constexpr because you have,

I mean, it's impossible for the thing to go past that point. So why not at least allow the final to be constexpr but now we can do things with like hypothetically runtime dispatch that happens at compile time and a constexpr context based on what the type of the object pointer was that was passed to the thing um i mean you know i'm all in favor of more constexpr things yes this is leading you closer to constexpr all the things oh it is very close at this point yeah yeah okay yes the next ones now i'm not sure where we're going with the rest of it yeah so atomic ref i didn't read too much into that one uh shift left and shift right algorithms um i think I briefly looked at that one and it's kind of doing the same thing as move and move backward

in simpler syntax. Yeah, okay. Yeah. They're removing some facilities that were deprecated in C++17. What are these? Ispow2, some facilities that were deprecated in C++17. What are these? IsPow2, Seal2, Floor2? I believe those are binary versions of these things. Oh, okay.

Yeah, well, integral powers of two. It's all things that are powers of two. And I read a comment on those here in this Reddit discussion about like, oh, I'm so glad to see POW2, SEAL2, and FLOR2 because anyone who does X has to reimplement these every time. And I'm like, I've never seen these functions before. I have no idea what their utility is, but I'll take your word for it. There is one, bitcast. Okay. okay so reinterpret cast not a hundred percent of the time but nearly a hundred percent of the time is used incorrectly in a way that invokes undefined behavior technically okay bit cast

is a defined way of doing these things i have a blob of data i want to cast it to some other type let the compiler do the most efficient thing that it knows that it can do in a not ub way that's awesome because currently to get around this we have to do things like mem copy from a data stream into a struct which is almost certainly going to be optimized away by the compiler but in this way yeah this should be good okay and jf is the author of it yeah i i feel like i remember talking about big cast earlier with uh maybe not with jf but talking about one of his articles earlier that sounds really familiar to me now yeah okay so now he's kind of in this trip report going over individual uh progress made in the different working groups so one of the things i wanted to highlight

was the uh executors okay um they you know i think you know we're talking about the optimistic versus conservative estimate i think it was definitely being put into C++23 as the conservative estimate last trip report. But they're now saying it is at least going to make it into a TS in C++20 and could quite potentially make it into C++ 20, the standard, the IS, because they're going to have an additional meeting to try and kind of hash out the remaining issues with executors, right? That's what it seems. I mean, and that's a big deal because we need executors to get networking.

Right, right. There's, I think, a that's a big deal because we need executors to get networking. Right, right. There's, I think, a whole bunch of other features that are kind of dependent on getting executors in. Yeah, executors and the updates to the, excuse me, networking and the updates to futures for sure. Right, right. And a better future or something, yeah. People did a lot of puns around the updates to futures,

and I'm terrible at them so yeah i i hope this additional meeting they're going to have goes well because if we get executors into c++ 20 then that kind of will hopefully push up the schedule for everything else like networking yeah now um the sad note for a lot of people paying attention to this is contracts excuse me not contracts concepts concepts okay you know what yeah we i need to take two steps back okay i mean to say modules both of those times modules modules is the thing that everyone wants but is nervously optimistic about, right? We already talked about concepts. Concepts are in. We already talked about contracts. Contracts are in.

I don't know why I said those things. Ranges are in, it looks like, because they rely on concepts. So that's good. Modules. Right now, it's saying to expect TSV2 and c++ 20 not yet necessarily being accepted into c++ 20 but that's the conservative estimate the tsv2 they're optimistics still set for c++ 20 and yeah we we said there's going to be an executor's meeting there's i'm not sure if it's the same meeting but they're they're also going to have a special meeting

just on modules. Okay. Yeah. So, yeah, 2018 fall EWG modules meeting and 2018 fall LEWG SG1 executors meeting. So, you know, the committee members who are willing to go to an extra meeting to try to hash out these features

and get them right for C++20 deserve a lot of credit. I'm glad they're doing it. Yeah, that's pretty interesting. That's, yeah, cramming in two more meetings. Maybe they'll let people call in. I don't think the average listener appreciates just how much traveling the average committee member does yeah i mean assume like a week and a half to two weeks for each committee meeting because you have to deal with jet lag and whatever and they're a full week long and there's what four of them every year so you're traveling for at least six weeks out of the year just for committee meetings. And if you're on the committee, you're probably traveling and going to conferences

and other things as well. Yeah. I mean, just as like, uh, take someone like Chandler for committee meetings, plus all of the clang and LLV meetings plus the conferences cpp con and other c++ conferences sure yeah it's a really truly a lot of traveling and they do all that traveling and then they just sit in meeting rooms all day yeah pretty much yeah um so yeah that's modules and executors uh what else do we want to talk about? The tooling study group had another meeting. This is their second meeting ever. And it says they had representatives from most of the major C++ package managers.

Obviously, we talked to Robert from VC Package last week. He was there, but I believe someone conan must have been there as well and they put out um two papers uh c++ dependency management package package consumption versus development and i read that paper a little bit and it sounds like they're basically recognizing that other languages kind of have learned a lot with their package managers and are kind of starting to do smarter, more innovative things. And if C++ is going to have a good package management story, we should try to learn from what these other languages are doing and get it right if we're going to be standardizing something.

That sounds reasonable. Yeah. And there's another paper on modules modules macros and build systems so i'm glad that they're uh starting to discuss how modules might work with package managers um i guess we should talk about the 2d graphics proposal since we talked about that a bit last time uh on our last trip report so they you know as we talked about last time it seems like the 2d graph proposal got kind of got hung up um and i've been going along for years chugging along and suddenly got met with some opposition um with this committee meeting, there was an actual like alternative graphics proposal paper written.

And the alternative proposal is basically kind of for the most part saying we should just stop working on this. Right? Yeah, that's what it seemed. Yeah. Um, so it sounds like they, they did a vote on whether they should go with this alternative proposal or continue to work on the graphics proposal and that vote, it sounds like it was kind of split. Yeah. Go ahead.

No, no. Yeah. So, I mean, with the vote being split, it sounds like as of now, we're,

we're still going to be in limbo with this graphic proposal. You know, some people might continue working on it, but it's not advancing towards the technical specification and definitely not towards the international standard. Yeah, it seems to have just effort just to go to these committee meetings, but it's even more effort to be writing these papers and working on these libraries. really feel bad about all the time that several people have spent on this but i i can't disagree with everything that was being said in that alternative paper did you read through that one i did not know yeah so it kind of highlighted um the reasons why um this particular graphics proposal didn't really make sense. It kind of didn't meet some of the original requirements that were stated for having graphics in the C++ standard. And on top of that, it kind of highlighted that

maybe this issue is really about package management. If we had better package management, then we wouldn't care to have a built-in graphics library and uh and yeah i think everything they said was absolutely true they they did outline an actual alternative um proposal to um create this small library to place things on the screen because apparently the actual graphics proposal you know you need to work with i guess like drawing lines and triangles um what they were saying is it should be better if it would be better if it could you know load up assets and draw those that might be more useful to uh developers and such. Yeah. Yeah.

I don't know if you noticed, but Guy Davidson did also publish his own trip report with his direct experience about this. Yeah. I read through some of that. What was your take on that? Well, it seemed very disappointing to him, which is understandable.

He put a lot of work into it. But then he did have this little note here. He says several thousand hours of work had gone into the proposal. We need a way of preventing this from happening again. Sentiment transformed from strong long-term support in Toronto to ambivalence in Jacksonville, and then basically an end here in Rville yeah and i'm curious how it got so far without meeting this kind of pushback earlier i mean has the concept of package management just become more discussed lately and that made everyone think hey maybe that's a real problem maybe we shouldn't be shoving all this into the standard i don't know honestly that doesn't seem like it should be that much of a new thought. I don't know. Yeah. I don't know. And, you know, it could just be opponents who were choosing to speak up now

who didn't before or something. I honestly don't know. And having not been to any of the meetings, I don't really know how these things really go down and i'm sure we can read all the all of this trip reports that have ever been written and and still not really know what it feels like to be there during the conversation of these things yeah i'm kind of curious as to whether did this particular paper like was it brought up in some context every single meeting or did they kind of go off for a year or two and work on their own without going back to the committee for feedback yeah and i have no idea yeah uh okay is there anything else that i i missed jason that we want to talk about um just one quick comment that bry trip report says, plus a variety of fixes too long

to list here. I really want to know what that variety of fixes is. I tried to find more information and could not. I don't know if I'm going to have to go look at individual papers, but there was a bunch of like tiny more updates to constexpr in the context of standard algorithms uh basically specifically standard swap is not constexpr and therefore none of the algorithms that rely on it such as standard sort can be constexpr so uh one of the fixes that i was expecting to see come through in this was making swap constexpr and therefore the cascade of the rest of the standard algorithms

that don't require any dynamic allocations being constexpr that's something i'd really like to see i currently have some hacks in my code that do compile time constexpr uh um sorting without using the standard sort and i would like to you know be able to get away from that kind of thing and see that in c++ 20 but i i don't see any updates on that particular paper okay one more uh study group trip report that i thought was interesting was uh the undefined behavior study group uh who said they adopted a policy that not all undefined behavior has to be preserved from one version of c++ to the other and i thought that was really interesting you would have thought that the they would have already had a goal of reducing undefined behavior but now they they're, I guess, explicitly saying, yeah, we don't, we don't feel any need to preserve UB. Yeah. And there's, you know, people that argue that we don't want to get rid of all the undefined behavior because a lot of this is where the compiler is able to

operate and do things that we like it doing in the realm of undefined behavior. Um, I don't feel like I'm well-in informed enough to have a strong opinion in either direction on that. But I do know that technically, undefined behavior is not allowed in a constexpr context. So the more work that you do at compile time, hypothetically, the less undefined. Yeah. Although that exact definition, others are quick to point out, is highly dependent on the compiler, like what things it is going to actually fail to compile because they're potentially undefined behavior. And like I just tested this myself, like signed integer overflow does not exist in C++. That is undefined behavior. So I wrote some constexpr code that does sign integer overflow

just to see if it would compile and it totally does compile on every compiler that i tried in a constexpr context so it clearly doesn't check everything um but it's at least you know another thing to look at okay well i think that's everything i wanted to cover from this uh you're good yep i'm good okay well we should be back next week with another guest uh thank you everyone for listening and uh see you next week later thanks so much for listening in as we chat about c++ i'd love to hear what you think of the podcast please let me know if we're discussing the stuff you're interested in or if you have a suggestion for a topic I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com.

I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. 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 is provided by podcastthemes.com.