CppCast - SG15 Tooling Group

Episode Date: June 28, 2018

Rob and Jason are joined by Titus Winters from Google to discuss the SG15 Tooling Study Group and revisiting the concept of regular types. Titus Winters has spent the past 7 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide. News Dependencies C++ 20 in Tony Tables Announcing Template Intellisense East const Central Trip Report: C++ Standards Meeting in Rapperswil, June 2018 Titus Winters Titus Winters Links Tooling - WG21 Tooling Study Group SG15 Revisiting Regular Types Sponsors PVS-Studio February 31 Patreon CppCast Patreon Hosts @robwirving @lefticus

Episode 156 of CppCast with guest Titus Winters, recorded June 28th, 2018. Try the demo version today at viva64.com. In this episode, we discuss Tony Tables and Template IntelliSense. Then we talk to Titus Winters from Google. Titus talks to us about the SG15 Tooling Study Group and regular types. Welcome to episode 156 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm alright, Rob. How are you doing? I'm doing fine.

You surviving there over in Europe? Yep. Two-week trip, heading home soon. I've had five successful training classes since I've been here. Wow, that's a lot of training. Yes, I am not used to standing up on my feet and talking all day long for this many days straight. Well, we will be glad to have you back in the States soon, okay? Yeah, it might make some recording a little bit easier again. Yeah. Well, at the top of your episode, I'd like to read a piece of feedback. Jason, I really love our listeners.

I don't remember the full context of when we were talking about Dependency Walker, but I think we were talking about that a couple of weeks ago. Yeah. You remember that conversation? So yeah, dependency Walker and how it hasn't been updated in years and was running really slow and doesn't understand some of the newer windows APIs and DLLs and whatnot.

Okay. So, uh, Rob Condie wrote me this email, and he says, you mentioned the staleness of depends on the show, so I thought I'd share this. Just checked it out briefly,

but it appears to fix all the false positives and runs much faster, probably because it knows where to find the DLLs. And this is at github.com slash lucasg slash dependencies. And I downloaded this repo and built it today, and it does run much faster and has a you know more up-to-date user interface and it's just fantastic awesome yeah so in a while since i've needed a tool like that myself but yeah well if anyone has tried to use dependency

walker recently and found it lacking I would highly recommend checking this out. Okay. Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or emails at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us again today is Titus Winters. Titus has spent the last seven years working on Google's core C++ libraries. He's particularly interested in issues of large-scale software engineering and code-based maintenance. How do we keep a code base of over 100 million lines of code consistent and flexible for the next decade? Along the way, he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale and helps maintain the Google C++ style guide. Titus, welcome to the show.

Hey, good to have you. Thanks for having me. You know, Titus, I think when you were last on here, I did not ask you any questions about how you got started with C++ or maybe even how you got started programming. Yeah. how did you get started uh so i got started programming oh let's see i was 12 and my dad uh for holidays and things would usually like uh buy you know gifts like people do and for a few years uh the kids got like little bags of candy or something from the candy store at the mall. And that year in particular, for some reason, he decided to go to the bookstore instead. And I don't know what my little brother got, but I got a book, Learn QBasic Now, or some such thing. And I just started poking at it.

I basically self-taught from there. I found some friends at school that also programmed and kind of just took that up as a very all-consuming sort of hobby. I think I was, let's see, it was probably like 95 or 96 that I first picked up C++. No, it must have been earlier than that. It was probably like 94 when I first picked up C++. And yeah, I've been never far from C++ since then. I have been, I think, accidentally one of the C++ experts

in a lot of the places that I've been without ever really having a great formal training in it until really recently at Google, being around people like Chandler and Richard Smith. And yeah, it's just been around with me for a long time now. I guess it's probably more than 20 years coming up on 25 so is that high school or college when you first picked up c++ from q basic uh it's probably middle school oh middle school wow yeah okay well titus we got a couple news articles to discuss uh feel free to comment on any of these

and then we'll start talking more about uh sg15 what went on at wrappers will and about this regular types article you wrote okay sounds good okay so first one um uh tony van eerd i think we talked about the c++ 17 tony tables uh collection he put together uh you know when c++ 17 was coming out and he's now working on the same thing for c++ 20 and so far there's only uh five tony tables to look at but i'm sure he'll keep this updated as c++ 20 continues to progress and these are just nice little side by side snippets of code showing you you know how something can be done in C++20 versus previous versions and how it's become more condensed and easier to read code, which is really nice.

Yeah, I'm really a big fan of the things that Tony's been doing and the popularization of the term Tony Tables. We started hearing him and other people use that in the standards committee in WG21. And it's clearly so much better when proposals come with actual before and after. Because it is really sad to say, but the vast majority of the proposals don't. And that's

a real shame. The clarity that comes from just, just tell me what you're doing. Uh, it's really valuable. Yeah. And I know we we've talked about the spaceship operator a couple of times and that one, I really liked the Tony table just cause it goes from, you know, like 40 lines of code to like four maybe. Yeah. The spaceship is going to be great. I'm really, really pleased with how that maybe. Yeah. Spaceship is going to be great. I'm really, really pleased with how that works. Yeah.

Uh, anything you wanted to highlight, Jason? Yeah. Uh, yeah, I mean, I,

I agree. This is pretty awesome. I was hoping for a little bit more completeness since I know there's more than this. It's been approved, but, uh, it's good to see that he's maintaining it.

And on a side note, I have, around here in the Netherlands, seen signs for the Van Eerd group, but I have not managed to get a picture of one yet. What is the Van Eerd group? That's just some company out there? That's just some random company, but Tony Van Eerd, you know, I thought it would be kind of fun to shoot him a picture.

Nice. Okay, next thing we have is a post from the visual c++ blog and this is announcing template intellisense and this is pretty cool um if you have some templated function you can kind of evaluate uh how it's going to work by putting in some sample argument and kind of being able to debug your template function i don't think any other ide has anything similar to this so i thought this was pretty pretty impressive uh there are other ids that will let you see an instantiation of a template but i'm not aware of anything that'll let you type it in like this does. Yeah, I've been seeing

good things from JetBrains in similar fashion, but yeah, there's so much room to make that experience better. And I believe Cvelup, or however you pronounce that, is also a template visualization. Oh, yeah. Yeah, I've heard that.

Next thing we have, we talked before about John Kalb's blogs and found love of East Const, and he wrote this new post called Welcome to East Const Central. And I guess it's a little tongue-in-cheek, but he's going over all these different blog posts talking about the benefits of East Const or Consistent Const.

And he's putting out a petition for Const Consistency, which is asking, I guess, for the C++ core guidelines to use East Const over West Const. And he actually has quite a few people who have signed this. What is your take on East first West const? Definitely West. Oh yeah. Yeah.

Like I, I understand the sort of technical arguments for the East const folks, but it's sort of similar to whether the star or the ampersand goes with the type or the identifier. There's a fairly direct parallel there between which of these

is technically consistent, and which of these is how a human brain works. And I'm inclined to prioritize the latter, because the compiler should serve us, not the other way around. Yeah. So I've been thinking about this a lot, too, Rob.

You used to live in New Jersey. Uh-huh. Have you ever seen these intersections where to turn left, you actually have to get in the right lane? Yeah, the jug handles? Whatever they're called. Yeah. these intersections where to turn left you actually have to get in the right lane yeah the uh jug handles right whatever they're called yeah so it makes like it's technically superior because you don't have a bunch of people backed up at the light because you have to do this thing where you get in the right lane and you do a loop and now you're in the correct lane to actually be heading left. But no one on the planet expects to have to be in the right lane to turn left.

So even though it has technical, yes, it might have technical superiority, but it is not at all what anyone expects. This has been my thought lately. I will leave it at that. I like your way of thinking. Yeah, that's a good analogy. Okay, and then the last thing is yet another

Rapperswool trip report. This one is really, really thorough. So I would recommend anyone who really wants a good overview of everything that happened at Rapperswool to look at this article. And I'm not sure who it was that wrote this one.

Does anyone know who this author is, Baton Bolo? I'm not sure. Yeah, I think he hangs out mostly in the language evolution groups. So I don't interact with him much. Yeah, really well done. Very good trip report. That pretty much covers everything, as far as I can tell. I think most of the trip reports tend, like, most people that write trip reports are wandering

between rooms. And it's important to keep in mind that there's at least five meetings going on simultaneously at every standards meeting. And I think for whatever reason, there's always a larger crowd and more immediate interest for language evolution proposals. Okay. language evolution proposals. Whereas the amount of discussion and the number of proposals that go through something like library evolution is usually... I mean,

we're running the same amount of time. There's a lot more proposals by count that go through library evolution. So there's a funny sampling difference going on. And my biases show because i i'm library evolution you know forever lost you for a minute there but i think i gather that you notice that there seems to be a focus on uh core evolution and not library evolution in his paper? Yeah. Well, and in most of the papers, in most of the trip reports.

Okay. Right. Well, he did mention SG-15 at the bottom of his trip report, so maybe that's a good time for us to segue into the main discussion. So we first heard about SG-15 on the show after the Jacksonville meeting, I think.

How did the tooling group get started? I don't really know. Like, Herb came to me, I think, in Albuquerque saying that there was some notion, and I don't know where it came from, that there needed to be a tooling working group. And I asked what exactly that would entail, and no one was entirely sure. And I certainly have been talking about tooling issues, and my work at Google is all focused on tool-assisted code migration and use of tooling for analysis and understanding and monitoring of what's going on in the code base. And so they tapped me to chair that group with no particular mission statement in mind. So there was a large meeting in Jacksonville to try to kick that off. And there's a public open mailing list that I encourage everyone to go look that up

and sign up for if you're interested. But roughly what it looks like the tooling group is working towards is to try to put out sort of goals and guidelines for the various groups that work in the C++ ecosystem to try to point us towards, like, build understanding and support for tooling, support for both, like, dynamic and static analysis tools, support for indexing, support for refactoring tooling,

to try to help the ecosystem as a whole have a little bit more coherence to try to help the standards committee understand the scope or difficulty of changes that are being proposed and to try to kickstart a stronger, healthier tooling ecosystem for C++. So if there's a proposal to the C++ standard that maybe has some unintended consequences for tools, then this SG-15 might raise awareness and say, oh, by the way, this thing that you're proposing would be impossible to work with in an IDE or impossible to work with in a refactoring tool or whatever. Is this? That's one thing, yes. And there has actually been a couple papers along those lines. Tom Honerman sent a paper very much along those lines expressing concerns about the impact of modules on certain types of code understanding tools and code refactoring tools.

So that's one thing. Sort of coming at it from the flip side of not SG-15 warning the committee about that's going to make some things hard, but SG-15 telling the committee, no, actually, that will be easy. One of the things that I've been pushing for for about a year now is P0684, and this is my idea that C++ either needs to prioritize stability to a greater extent, and we need to be slower, effectively. We need to be very, very sure that everything that we're doing is right. Or we need to prioritize mechanisms to make changes if we are moving fast with the assistance of tooling, and very much like Abseil's approach to,

we'll ship a tool if we have to make a change that breaks you. We're trying to push the standard towards considering doing similar things. And one of the things that I expect will come out of SG15 is sort of a list of, these are the refactoring primitives that we assume everyone has access to that will work well. And if we rely on those, then making certain backwards incompatible changes will be annoying, but not the end of the world. So I assume you already have some notion in mind for what these primitives might look like? Yeah, I mean, the obvious things are sort of, you know,

renames or I think actually renames covers sort of the obvious spectrum, and that could be renaming a class, renaming a member in a class, things like that. Even just producing warnings to suggest, oh, your custom site container has tags in it that didn't used to have any meaning, but the standard has now started adding meaning to those tags. And you might want to make sure that you're opting into what you think you're opting into. So it could just be analysis, it could be help with refactoring, renaming, all of these things.

Okay. So we're talking a little bit about analysis and refactoring, but from what I read from the Wrapper Swill trip reports, it sounds like a lot of discussion at SG15 this year was around package management. Is that right? Yes. I think one of the sort of hot topics in tooling right now is in dependency management and build understanding to a lesser extent,

which sort of all goes together. One of the things that I want us to get towards is the idea that the standard is not the only place to put things and that there's still easy mechanisms to distribute and build with and link all of the things that you might need access to. GitHub has certainly made it much easier to distribute source, but I do not currently find it terribly easy, certainly not terribly consistent, to have access to whatever dependency you happen to be looking for.

We're making some progress. Conan and VC Package and a couple of the other ones in that space are making great strides, but there's not one clear winner by any means, and it's not entirely clear that we're, let's say, providing enough guidance on how to produce and maintain a package to make that really quite as easy and off the shelf as it will eventually need to be. So do you foresee a future where where I'm reluctant to say this, but the standards committee would actually prescribe like a build system, say this is the officially recommended way of,

of pack of building a C++ project. And this is how you specify requirements. And then everyone can work from that standpoint? I think it's unlikely to come out of the Standards Committee itself. Okay. Partly because the Standards Committee is just not really well positioned. I don't know what the shape of that as a document would look like from an international standards perspective.

But that said, I think there's plenty of room for something like core guidelines, for instance, to put together a not one true build system, but this is how to lay things out, this is how to depend from one thing to another, this is what you should be thinking about if you're trying to produce a stable and usable package, you know, uh, and then tooling to help, um, you know, monitor whether or not you're doing that properly.

Like a linter for is your package actually, uh, dotting all of the eyes and crossing all of the T's. Right. package actually dotting all of the i's and crossing all the t's right so it's uh from guests that we've had on this show it does seem like there's some current concerns about how modules can work in the real world and how our build systems can reason about them and you alluded to modules a little bit ago was was there any discussion about modules and how they would impact our build environments and what needs to come out of it from the first SG15 meetings? There's been a little bit of discussion as to

if there was a standard and very detailed modules like metadata format that described in fairly great detail the API surface that was being exported by that module, then that would presumably help with tooling. But that there was sort of a back and forth, I think primarily, if I remember correctly, between Chandler and Gabby, who sort of represent two usually very opposite camps in the module space,

and both of them were sort of hesitant to imagine that there would be a standard and consistent format for that, or that that format would ever be sufficiently detailed and accurate, and that in fact probably the right way to express all of the semantics and all of the API detail is actually the code. And so there's a notion that a lot of people seem to feel like modules as a distribution mechanism rather than really just being a build mechanism. And I think that's not actually the case.

And if we're using modules purely as a build model and not a distribution system, then that becomes a little bit more clear, I think. Okay. So what else did SG15 discuss at this first RIPERSWOL meeting? Let's see. What else did we talk about? It was a lot of, it was some package management demo. It was some discussion of sort of long-term goals and still trying to really agree on a mission statement for SG-15,

which there's some sort of rough ideas of a mission statement, but it's very focused on providing things to the committee. So the mission statement, as I have currently phrased it, is very committee-focused because all of the people that are working towards it are committee people. In my belief, that's sort of bad optics, but if we achieve that mission, it will be good for all of the community and all developers everywhere. And the way that I currently have it phrased, and I'm very open to' time, the committee should be able to consult an index of popular open source projects, a compiler-based index of popular open source projects,

in order to understand what C++ code in the wild currently looks like and use that to inform choices about proposed changes to the standard. And what I like about this is it sort of implies, okay, so there's clearly has to be something like a package manager so that we can define what are the popular open source projects. There has to be something like build understanding if you want to be able to run an indexer over those things. It would greatly increase the committee relying on data instead of feelings and argument. Um, because it is unfortunately the case that almost no committee attendees have actual data about the code base that they represent. Um, Google does to some extent, Microsoft does, uh, of late. Um, but, uh, like a lot of what I was doing for library evolution, the first couple of years that I was there was when api proposals were made i could say oh yeah we have one of those and let me go check our indexer no one uses it this is not

important uh and you know that sort of is anecdata because that's just how things happen to be in our code base but um you know in the land of blind, the one-eyed man is king. When no one else even has ANIC data, that's not very helpful. And then going back to the mission, if we have all of those things and then can use that to inform deployment of tools when making changes to language, that's great. And for any committee members or representatives where your code base is wildly different than what's normal in the open source world, well, then you'd better send a representative with

an index of your internal code base to represent your perspective. Otherwise, that's on you. So I like the outcomes of all of this. I just understand that it's sort of phrased funny. So is SG 15, uh, since you're working on the mission statement, uh, I was wondering if you're going to be, um, meeting just at committee meetings, or is this going to be one of the study groups that also has side meetings from time to time outside of the normal committee meetings? I would like us very much to have side meetings.

I have unfortunately just been recovering ever since Rapperswell, so I have not actually started organizing anything or got my head back in the game. But it is certainly my hope that we will have, if not more. I've been trying hard to get some of the mailing list chatter to continue to have good discussions there. That's been sort of fits and starts.

I think having something like Skype meetings or something might be a good place to start. So I'm hoping that we go there, but no promises. It sort of depends on when I can get my act together. So is the mailing list something anyone can join currently? Yes, absolutely. Unlike the normal WG21 reflectors where you're at least sort of asked whether you have something to do with uh the committee um the wg15 sorry the sg15 uh mailing list is totally open um if you go to isocpp.org you can find links for it

i think awesome i'll have to uh include that in the show notes so any listeners who are interested can uh can join that'd be great um one of the fairly new group i think is the directions group right um yes you want to talk about that a little bit so the direction group uh is sort of a invite only uh standing group of uh respected elders i suppose people that have been involved in the process for a long time and that ideally can represent a broad selection of constituents. And the point of the direction group is largely not to approve papers or forward proposals or anything like that, but more to try to suggest areas that would be good to work on,

suggest how to prioritize between one proposal and another, or proposals in one domain versus a different domain, all of which is very good. Vila, who runs the Evolution Working Group, and myself running the library evolution working group, both of those groups now have more proposals every meeting than we're likely to get through in that meeting. So having someone else that's sort of a more neutral third party that is in charge of setting direction for the language as a whole and being able to rely on their input for which things should we be prioritizing.

Takes some of the burden off in that, which is nice. Okay, interesting. So they're not specifically telling you which proposal to go after or not to go after, but kind of just giving you an overall direction of where the language is and where you should focus your effort. Yeah, like which major pieces of work seem most important. Let's devote significant time and resources to these. Interestingly, they're sort of sketching that out not in terms of any particular proposal on the table but in terms of we believe that this is important for the language and for the community

so there was certainly some discussion from them on we believe that graphics is important without getting into which competing graphics proposal they wanted to see. And then I guess, as I think most people have probably heard by now, the direction group is clearly non-binding because the committee as a whole was not willing to commit to putting more work into graphics. I wanted to interrupt the discussion for just a moment to bring you a word from our sponsors. PVS Studio is a static code analyzer that can find bugs in the source code of C, C++,

and C-sharp programs. The analyzer is able to classify errors according to the common weakness enumeration, so it can help remove many defects in code before they become vulnerabilities. The analyzer uses many special techniques to identify even the most complex and non-obvious bugs. For example, data flow analysis mechanisms, which is implemented in the tool, has detected a very interesting bug in the protobuf project. You can read about this bug in the article February 31st. The link is under the description of this podcast episode. The analyzer works under Windows, Linux, and macOS environments. PVS Studio supports

analysis of projects that are intended to be built by such common compilers as Visual C++, GCC, Clang, ARM Compiler, and so on. The analyzer supports different usage scenarios. For example, you can integrate it with Visual Studio and with SonarCube. The blame notifier tool can notify developers about errors that PVS Studio detects during night run by mail. You can get acquainted with PVS Studio features in detail on viva64.com. So Titus, you also recently wrote this blog about revisiting regular types. For listeners who aren't familiar with that term, what is a regular type? So regular type is the term describing the sort of ideal design for a user-defined type to try to make it behave as much as possible like a built-in type.

So this is where the term that you regularly hear of do what ints do comes from. And so if you think, or this is the slightly more formal, slightly more theoretical term for I'm building value types. We call those types regular. And this was Aleksandrescu and, no, not Aleksandrescu, Stepanov in the 90s sort of wrote out some of the sort of initial formalism for all of this. And most of the types that we work with in the C++ standard library behave very much

like they are regular. they copy and they compare and they're ordered and all of these things in the same fashion that an integer or a value type would be there's some differences in various places, floating point has some irregularities around NAND and inf the fact that default initialization for integers is undefined if you read from it. It's probably not the ideal thing to look at. I sort of like do what string does as a better thing.

It's just not quite as pithy. But by and large the idea is this is the set of design steps to follow in order to produce a type that is going to behave in a way that doesn't confuse people.

Because, you know, it is C++. You can make your type do whatever crazy thing you want it to do. If you want operator equals equals to be the way that you spell fire the missiles, you can do that. You just probably shouldn't. Okay, so what about these type design guidelines needs to be updated in the era of c++ 17 and 20 so i think it actually started

getting more complicated a little bit with 11 and the fact that we had move semantics the original papers on regular talk a lot about swap you can sort of read into it uh the ideas of what to do with uh like destructive copy or or you know a move sort of behavior um but once we got into c++ 17 that was time that we really had a type in the library that is regular depending on how you use it ish which is not really regular um and that for that i'm talking about string view um string view if you happen to just be using it as a parameter type, and you know that the function that is calling you, that parameter is not being changed out from under you, then string view behaves very much like a regular type. But all of the other ways that you can use string view are not regular and that certainly had some contention from members of the committee at like at the point that we were introducing string view

and then we took the additional step of starting to talk about span and string view you know set some precedents and then span does the same but but also allows you to take a span and mutate through it, mutate the underlying sequence, which is a out, like, okay, is string view really okay? And if it is, is span okay? And if not, why not? And so the blog post that you mentioned there, which I'm very proud of, is my attempt to try to go back to really basic design principles and really go back and look at, now that we've advanced 20 years, what does it mean for a type to be regular? Does the original formulation cover all of the things that we want from a type? Notably, one of the things that has changed there is everything's multi-threaded now.

We really have to talk about the threading behavior and thread safety of your type. And then with all of that as a basis, what does a good type look like? Okay, yes. I have seen a fair bit of this discussion about whether or not string view is a regular type and um i don't know i was just reminded when you when you started the explanation of the regular types now things got complicated with c++ 11 one of the things that i'm often asked when I'm teaching move semantics is what does a moved from object

look like? And the answer is, it's like you said, you know, if you want to spell fire the missiles as operator equals equals, right? Like, what does a move from type look like? Technically, whatever the implementer of the library implemented it as. Although I do think we have one, and I don't know if you said this because my audio is a little rough on my side here. One previous example of an irregular type in the standard library. Autopointer? Autopointer. Oh, yes. Yes.

Yep. That was before my time, But clearly, mistakes were made. Yes. Definitely mistakes were made. Yeah. Even without getting into Autopointer and all of its horrors, as I was sort of suggesting, even as of 11, we start having types that are not regular but not bad uh unique putter is not regular a regular type is copyable okay right um int is copyable string is copyable

um and so there's there's clearly some other families of types that are of design that are okay. We can work with move-only types. It's not super impossible. It's a little frustrating when you're learning it, but you can work it out. In C++17 we can work with types that are neither

movable nor copyable and still return them from functions. True. I have not seen a lot of that going on, but I do like that as they're movable nor copyable and still return them from functions. True. True. I have not seen a lot of that going on, but I do like that as a, as an avenue for implementing like factory functions and things. Yeah. One of the things that I talked about at C++ now,

and I have to give credit where credit is due. I think the, the first person to suggest it to me was Matt Calabrese. The suggestion that any subset of regular is probably still good, which I think is a nice formulation because all of the things that we don't mind, like unique putter and move-only types, or if you go to the concepts sort of hierarchy,

semi-regular types are regular except not comparable. Those are useful and hard to misuse. So I sort of like the notion of everything that is a subset of the properties of regular is probably good. Okay, so then on that topic, string view and span aren't really a subset of regular either, right? They are not. Okay. And this is where it gets interesting. So one of the things, and I'm begging for terminology here because I do not, I hate naming things. So I'm a weird person to chair, L-A-W-G. I hate naming things. But one of the properties that I find very interesting when talking about types is, are there APIs, are there methods on this type that have preconditions that you cannot check without knowing something about the program?

Which is a weird notion, right? But the idea is, if you look at something like optional, I just hand you an optional, you know nothing else about it, but I hand you an optional. You know nothing else about it. But I hand you an optional. You can ask it has value before you try to extract the value out from it. If I hand you a string or a vector, you don't have to know anything about it. You can call.size on it before you index it,

or you can just iterate through it. These are things that you can do just based on the readable sort of API of the type. Whereas there are types that are harder to use whose preconditions

can only be really expressed in terms of the whole structural knowledge encoded in the program. They're not self-contained within the type. And string view is a great example of this. Like string view, you cannot use operator square brackets on string view without knowledge that the underlying buffer still exists and isn't being mutated.

And there's no way to query for that. Or similarly, there's no way to query for that. Or similarly, there's no way to query for can I dereference this int star? Or rather, can I dereference this int star and then either read or write it? Technically, the dereference is fine on its own, but that's kind of splitting hairs. Right, and this notion of having APIs

with dependent preconditions I find really satisfying because it finally actually gives us a way to say that, yeah, int star is actually harder to work with than int, even though in a sort of generic sense, both of them are regular. And so I think this finally starts carving a difference between those two things. Because, you know, if you survey, you know, all of the students that you just taught in the last week, right. And ask them which type is harder to work with an int or a string or an int or a, I'm sorry, an int star or a string, right. Like they're going to say int star, right. Because it

has preconditions that you cannot check. You have to know something about the program. they're going to say in star because it has preconditions that you cannot check you have to know something about the program that's an interesting point so a string view then or a span in that sense becomes kind of like a fancy pointer in some respects yes

it is a question of what knowledge you have to have about program structure that lets you use this safely. And so at the point that you have the knowledge that your underlying buffer exists and is not being mutated, then suddenly string view is perfectly regular. And span is still not, which is kind of fun.

Span, as it's currently specified, because it allows mutation, isn't really regular because of constness, which is another sort of important piece in type design. There's a relatively understood invariant that you cannot have all of shallow copy, deep compare,

and const propagation or const correctness in the same type. And so the trick there, for instance, is with a span as it exists in, say, GSL, if I have a const span of int, that's kind of silly. I can just make a copy of that, and now I have a span of int,

and I can modify right through that and do whatever I want. Okay. Right? Whereas this is not a problem for string view because you can never modify through a string view. And so by finally being able to say

under these preconditions of program structure, if I assume that the underlying buffer still exists, is that enough for this type to behave regularly? In the string view case, we get, oh, yes, yes, it is. And in the span case, we get, oh, no, actually, it really, really isn't.

And so with that, like, knowledge in hand, we're now entertaining a number of proposals to revisit span and sort of fix it up. I think it's going to be we either drop equality on span or make equality shallow, all of which will make it suddenly self-consistent. So some version of span has already been approved for 20, right? Yes, but 20 hasn't shipped, so we're still fixing it. Oh no, yes, definitely. Fix the things before they ship. I was just making sure I had my story straight. Yes, there is a version of Span in the working draft.

Tony Van Erd has a paper that we heard the first draft of in Rapperswil a couple weeks ago. And I think early in the next meeting, if not sooner, we will try to finalize exactly which fix we're going to take for Span to make it a little less broken. You know, given Tony reading a paper at rappers fill in you, the way you said, we heard this, I just imagined it as some sort of a present, you know, like a performance art of Tony reading this,

like perhaps it was written in prose. I don't know, but it had the largest flow chart I have ever seen in a proposal. I will say that. That's funny. And it was actually a very good paper. Like, totally in line with all of the realizations that I have come to on how these things play together. And his flowchart is basically, like, do we want this type to make sense?

Like, do you want it to be shallow comparison or not? Can we rename it? And depending on which of these choices you go through, you get to a slightly different proposal. So that was a good paper. Okay. Is there anything else you want to let us know about the recent Wrappersville meeting? Let's see.

I am extraordinarily excited by the new ranges design. There was certainly quite a bit of discussion coming out of Jacksonville that no, we're not just introducing namespace STD2. But that does not mean that we're not interested in ranges. So the change in design for how to merge ranges into the standard library is beautiful. I'm very pleased with it.

Sort of the very long-term goal is we're landing ranges in std ranges as a sub namespace, which I am very anti-sub namespaces in general, but I think this one I will live with. Then my sort of SG15 goal for the next few years is try to build up enough tooling expertise throughout the community, not just in my code base,

so that we can identify calls to the legacy algorithms and migrate those calls to the equivalent ranges invocations, which will almost certainly clean up a lot of things. And at the point that there's relatively little code left that is using the legacy algorithms i would like to switch uh all of those algorithms out of stood and into something like stood legacy and then a few years after that move stood ranges back into stood so this is a probably impossible like 20 year plan but yeah yeah that's a lofty set of goals. But that is, that is like,

I want to keep all of those things possible. Um, and it, the technical problems in that are actually not insurmountable in any way. Um, the sort of work that Abseil does day to day is very much on par with that other than the fact that we have actual visibility into the code that's being modified um so it's it's just that little hurdle so well i am already looking forward to this because i think you just promised this uh that there will be a cling tidy modernized check that will convert all of my code from uh current uh standard library to ranges not all of but yeah it's i think we will get as close to that as as is technically possible yeah yeah like clearly there's going to be some weird things that people are doing that this will choke

on but absolutely that will that i'm okay with that like it will just make it more obvious that you were doing a weird thing why why are you doing a weird thing right and for the listeners who haven't used the modernized checks in some ways they almost seem magical so i really am truly excited to see how this would look for converting to ranges yeah. Yeah. I mean, my absolute goal is to make sure that we do this design in a way that allows automatic transformation from one to the other to the extent that it is possible. Right.

That'd be very cool to see. Yeah. Like, the trick is that we have to sort of, at same time decide how many of the old mistakes we want to clean up. Because every time that we clean up one of those old weird bits, it will make some of that migration harder. So there's some trade-off in there. But no, that should be good so ranges was very good I'm terribly excited

we're def it looks very likely I guess I won't say definitely but it's extraordinarily likely that we're going to have constexpr containers and constexpr container which is with allocation

so we'll have constexpr vector. The design for that is so, so elegant. I'm terribly pleased with it. Yeah, the people behind that did a great job. And yeah, lots of good stuff. Awesome. Well, it's been great having you on the show again today, Titus. Yeah, thank you as always for having me. It's always good to talk to you. Yeah. 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 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.