CppCast - Ranges

Episode Date: December 8, 2015

Rob and Jason are joined by Eric Niebler to discuss his work on Ranges and the future of the Standard Library. Eric Niebler is an independent consultant specializing in C++ library development. Currently, he is working on modernizing the C++ standard library and adding support for ranges, funded by the first-ever grant from the Standard C++ Foundation. Previously, Eric was a consultant for BoostPro computing, a member of Microsoft's Visual C++ team, and a Microsoft Researcher before that. In addition, he has several libraries in Boost and is a Boost release manager and steering committee member. Eric has been an active member of the C++ Standardization Committee for well over 10 years. He speaks regularly at C++ conferences around the world. In a previous life, Eric drifted with no fixed address, writing C++ and blog entries from cafes and beaches around the world. Today, Eric is a family man living and working in the glorious Pacific Northwest near Seattle. News Clang with Microsoft CodeGen in VS 2015 Update 1 Conan a C/C++ package manager Getting started with Modules in C++ Eric Niebler @ericniebler Eric Niebler's blog Links Range v3 Library C++ Extensions for Ranges CppCon 2015: Eric Niebler "Ranges for the Standard Library"

This episode of CppCast is sponsored by Undo Software. Debugging C++ is hard, which is why Undo Software's technology has proven to reduce debugging time by up to two-thirds. Memory corruptions, resource leaks, race conditions, and logic errors can now be fixed quickly and easily. So visit undo-software.com to find out how its next-generation debugging technology can help you find and fix your bugs in minutes, not weeks. Episode 37 of CppCast with guest Eric Kneebler recorded December 8, 2015. In this episode, we discuss some of the new features in VS 2015 Update 1.

And we'll talk to C++ library developer Eric Niebler. Eric will talk to us about his work on ranges and the future of the standard library. Welcome to episode 37 of CppCast, the only 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? All right, Rob, how about you? Doing pretty good, and you're on mobile today, so hopefully we don't have too many issues, right? Yeah, I'm recording from a cell connection today, but I expect everything will go all right.

Yeah. So at the top of every episode, I like to from a cell connection today, but I expect everything will go all right. Yeah. So at the top of our episode, I'd like to read a piece of feedback. This week, Pavel writes in, and he says, Hey, guys, Apple just open-sourced Swift, and perhaps there's a chance to reach out to some of the Swift team and invite them to be a podcast guest. Since they're open-sourcing it, they might be willing to speak about it on a podcast. Love the show and keep up the good work. So I had heard about this, but I hadn't really read much about it. I'm familiar with Swift and never really tried writing in it. I have a little more familiarity with Objective-C. Jason, do you look into it at all when they open sourced it?

I just looked at, you know, some of the pull requests and the GitHub project and stuff, but I still haven't actually played with the language at all. Okay. It's definitely something worth looking into. And we have had the Rust and the D episodes. I'm not sure if Swift is as interesting to the C++ community as those other languages, but it's definitely something worth considering. If I could jump cue here and chime in, there is a

very interesting connection between Swift and the C++ community. One of the key developers on Swift is Dave Abrahams, and he is a co-founder of Boost. So if you could manage

to get Dave Abrahams to sit down for an interview, I think that would be really interesting. That would be. That would be a good show. Okay, well, since you're here, I'll introduce you, Eric. Eric Niebler is an independent consultant specializing in C++ library development. Currently, he is working on modernizing the C++ standard library

and adding support for ranges, funded by the first-ever grant from the Standard C++ Foundation. Previously, Eric was a co-consultant for Boost Pro Computing, a member of Microsoft's Visual C++ team, and a Microsoft researcher before that. In addition, he has several libraries in Boost, and is a Boost release manager and steering committee member. Eric has been an active member of the C++ Standardization Committee for well over 10 years. He speaks regularly at C++ Standardization Committee for well over 10 years.

He speaks regularly at C++ conferences around the world. In a previous life, Eric drifted with no fixed address, writing C++ and blog entries from cafes and beaches around the world. Today, Eric is a family man living and working in the glorious Pacific Northwest near Seattle. Eric, welcome to the show. Great. Thanks a lot, Rob. Thanks, Jason. So, you know, arguably here you are being paid by C++. Yeah, I am pretty much C++'s only employee, paid employee at the moment. Yeah. Yes. That was my next question. If there were other people getting paid from C++ to work on various research. So it's just you right now? It's just me. I'm the only one. Yeah. That's, how do you swing that?

Knowing the right people, I suppose. I don't really know. By being in the right place at the right time is what it was. And I think, you know, also, it just so happened that this thing called the Standard C++ Foundation was put together by Herb Sutter and a number of other guys a few years ago. And they are a nonprofit, and they accept donations. Companies like Microsoft and IBM and I don't know who else gives them money. And so they really had nothing to do with all of that money.

They just decided to fund some development. And mine looked like a good project to them. So I think it's going to be the first of hopefully what will be many grants. And so we'll actually have a quicker turnaround on some proposals because of it. That's something to look forward to in the future. Yeah, that's cool. Yeah. So we had a couple news items we wanted to get through

before we start talking to you about ranges, Eric. The first one was Clang with Microsoft CodeGen is now available in VS 2015 Update 1. So this is a new feature. It's in preview, but it's in Update 1. So if you use Visual Studio, you can try it out. And it's pretty interesting. If you have cross-platform libraries where you're building for Windows, but you're also building for Linux or iOS or Android, then you can actually use Clang in Visual Studio when compiling those libraries. And then you don't have to worry as much about ifdef in your code or not having certain features

available with Visual C++ compiler. You can do everything with Clang. Eric, I was really interested to get your perspective about this since you used to work on the Visual C++ team. Yeah, yeah. That was a long time ago. And this is really a departure from where the team was back then. Back then it was, you know, we're pushing Windows and we're pushing Office and

that was pretty much Microsoft's whole story. But it's really great to see that Microsoft is kind of moving forward from that position and is delivering a separate and highly standards conforming front end in Visual Studio. It's super exciting. I'm really glad to see things moving in that direction. I was so excited about it, in fact, that I installed it and played around with it a bit last week when it came out. What my hope had been that I would finally be able to use Visual Studio to compile my

ranges library and be able to use the Visual Studio debugger. Alas, it didn't work. And that's not to ding the Visual Studio guys. I was trying to use it for something it's not intended to be used for. But as it turns out, the Microsoft platform headers are highly non-standard. And so when you try to push them through highly standards-conforming front-end like Clang,

well, you know, hijinks ensue. And so it didn't really work out the way I had hoped it might. But, you know, I do hope that in the future, either their platform headers get a little bit more standards conforming or else, you know, they hack Clang to recognize their extensions. And that at some day, at some point, it will work, I hope. So basically at this point, if you try to include any Windows headers, just expect it won't work. Well, yeah, and standard C++ headers from Microsoft will include Windows headers, so they don't work either.

Oh, okay. Yeah. But I could have been doing something wrong, so I don't really know. I was not including any standard Windows stuff, but some stuff got pulled in that was using some wonky Microsoft extension and clang barfed. Interesting. They do point out in here that you shouldn't be using it for Windows UI.

So if you're doing your front end, you should still be doing that with Visual C++ compiler. But if you have a shared library, you should be able to target that with Clang. Well, then chances are good that I was doing something wrong. And hopefully someone who's listening

to your podcast could tell me what special magic compiler switch I need to pass to Clang to get it to eat Microsoft's headers. Okay. This next article is about Conan, which is a new open-sourced C++ package manager. And it seems like it might be coming from some of the same developers

who are behind B code. Is that right, Jason? Yeah, I think at least two of the people who worked on B code are also working on this project. I'm pretty hopeful for it. I was very excited about B code. Unfortunately, as we know, we announced the the death of the project on the podcast here. But hopefully this next one, maybe they learned from what mistakes they made on the last one or that you know made it not be as popular as it could have been yeah i know one of the main problems that people seem to have with b code was that it wasn't fully open source um

and you know they're not they're not they're not going down that same route this time they're they're making it fully open source even for for commercial use. So there really shouldn't be any reason for an interested company or group to try using this Conan project. Eric, did you take a chance to look at this at all? I did. And I couldn't quite figure out if there was a company behind it

and if this effort was funded or if it was like a volunteer open source sort of thing um but uh i think i think if there is a company behind it um it's going to be tough for that company to turn a profit you know that we saw that with a b code and it was unfortunate but kind of uh predictable um i I really think that package management for C++ is one of the hugest obstacles to adoption. And if C++ had a great package manager and a great repository for libraries

that it was easy to link to and install and download and compile and all that stuff, that it would be a huge boon for C++ developers. Something like Python's package manager, where you could just like... Things just work in Python in a really nice way. And C++ has been sorely needing that for a long time. And a lot of people have tried and a lot of people have failed.

And I really hope that now is the, and that this is the project. Um, but you know, I've seen a lot of projects like this come and go. So, um, you know, I, I'm hopeful, um, and, uh, happy to see where this goes. Um, it doesn't look like there's a lot of information on the website, but I do see that there are premium plans available if you want to host your packages privately or if you want to get some premium support using Conan. So there must be a company behind it

hoping to make some sort of profit. Almost kind of sounds like the Docker model where anything that's open source you can host for free on their server, or if you want to host your own server, you can, but if you want them to do it, then you have to pay them for closed source stuff, maybe commercial stuff.

Well, Docker's been incredibly successful, so it might be a good model to follow. Maybe, if I'm understanding that right. I'd love to hear more about it. Yeah. Okay, and then this last article is coming from Kenny Kerr, and it's a blog post about the new modules feature, which is also available with Visual Studio 2015 Update 1.

And he's really just going through a brief example of how to use the new modules features. And, yeah, it seems pretty cool. No headers files in this at all. He's just exporting a function with modules and then importing it using in a separate class. It's pretty cool. Yeah, I had a look at that.

And modules is super exciting. Like for language features and library features that are coming down the road, like concepts, modules, and like those are the two really huge outstanding features. And they're big and they're exciting. And I love to see Microsoft taking point on this. You know, I would also love to see the Clang guys and the GCC guys step up with an implementation also. And that way we could really get an idea of how good these ideas are in other compiler implementations.

But really, really excited to see Microsoft making progress on this one and driving the progress in this area. Modules, it's going to be, they're really going to help with, well, obviously modularization of your code, which is going to help development, but also for compile times. People complain all the time how slow their compiles are. Really are, you know, the text inclusion model that we've been dealing with since god knows what when was when was unix invented and see the 1960s right you know this like macro system that is just so archaic uh it would be

wonderful to do away with it and and actually have something that is quick and efficient and you know it actually plays into the package management thing because now we can ship modules instead of yeah um shipping binaries uh and having to deal with binary incompatibilities. It would be really nice. Yeah, definitely. Well, Eric, let's get started talking about ranges. For anyone who hasn't been paying attention to your blog posts or the CppCon talk you gave, could you give an overview of what you are hoping, what you're hoping to bring

with ranges to the future of C++? Oh, okay. So, so if you, if you've never say played around with a range library, like, like boost range, um, ranges are basically like a way of representing, uh, basically a range of data, um, which is, uh, you know, you have a begin iterator and an end iterator, but you kind of stick them together into one object, and you can pass that object around as a whole. That way, you know, you have algorithms that take ranges instead of pairs of iterators. It makes it much easier to call the algorithms. You could pass just a vector to std sort instead of having to call sort a vector.begin, vector.end. So that's, you know, in a nutshell what a range is. Why a range is interesting, because that's kind of, you know, not terribly exciting.

Ranges, they compose beautifully. So you can write range adapters that compose very well. So I could, like, take a vector, and I could take a vector and I could filter it and I could transform it and I could do all these other transformations to it, all in place, and then pass that lazily transformed range to an algorithm that can then operate on that thing.

And that way you have this sort of orthogonality and conciseness in how you're dealing with your data. And it makes it very data-centric, very declarative, and very powerful for the way these operations compose. So that's, in nutshell what range is Bayou is doing things lazily. It's very pure functional style so there's no side effects. You don't have to worry about threading issues. It's extremely high performance because underneath it all is all just the iterators that we know and love. So there's no like dynamic allocation, no type erasure, none of that stuff. And it all optimizes down to what you would expect if you were to write it all out by hand in C or whatever.

So ranges is going to be a huge win, I think, for programmer productivity and software robustness. I want to dig into this lazy evaluation for just a moment, if we can. So you're saying, like, when you go to dereference an iterator, excuse me, dereference, I don't even know what the right word is. When you go to get an element from a range, it would at that moment apply any filters or whatever the range was constructed with? Well, sure. So you were right when you dereference an iterator.

The way ranges work is a range is just any object with a begin and an end member function that returns an iterator and something that can be compared to an iterator you know what i'm calling a sentinel right and can return something that isn't actually an iterator in my model okay okay that's a detail it's not really terribly important at the moment but basically you get an iterator and then you you walk um you know just as as you would today you know once you have an iterator,

and you can walk through your sequence, dereference the iterator, you can plus plus that iterator to move to the next element, you know, just like the code that we all know and love. Thank you, Alex Stepanov. So what happens, it depends on what kind of a range you've created. So you had said a filter range.

When you dereference a filter range iterator, it's just going to give you the current element just like whatever underlying iterator would. The interesting bit for a filter range happens when you increment that iterator because the filter is going to be skipping over elements. So when you increment the iterator, it's not just going to move to the next element. It's going to move to the next element, check to see whether that element should be filtered out or not. If so,

skip over it and keep doing that until it finds an element that should not be skipped over and then it stops. So that when you dereference it, what you get is the unfiltered out elements. Okay. Now, if you had a transformed view, increment is not interesting, but dereference is interesting. Because when you dereference an element, you access the underlying element, and then you pass it through your transformation function. And the actual visited element that you get back is the result of that transformation function. So depending on what range you've created, either increment or dereference or both are customized in some sort of interesting way.

So how does that or can that work with sorted ranges? Okay. So if you've created, say, a transformed range, you've got a vector, you want to say, transform the range by maybe accessing a member of the underlying struct. So you've got a range of employees, and you want to access just the last names of the employees. So you write some sort of transformation that reaches into these structs and returns just the last names. So it's a transformation function from employees to strings. Although it's probably a transformation from employee references to string references. And now you have a range of string references.

You could pass this thing to sort, and it will sort it. That's it. Of course, you're going to be munching your data, right, because you've now, like, shuffled everyone's last names around. But anyway, that was a bad example. It gives you the basic idea. Okay. Okay. Yeah.

So in that way, it's kind of orthogonal to the algorithms. The transformations and the filters and the other range adapters are orthogonal to the algorithms. So a sort would be an example of an eager algorithm. It has to execute immediately. Okay. I don't know a way of doing a lazy sort. Would you have to do a partial sort of just the first element or something over and over again? Over and over again, which is going to be like some horrible n squared.

Yeah. Like I said, I just don't know how to do a lazy sort. There might be a way to do it. I just don't know how to do a lazy sort. There might be a way to do it. I just don't know. But I haven't implemented it, so I don't know how to do it. So the sorts of lazy algorithms that are provided by the range adapters, those are just the single-pass algorithms that can be done lazily. Okay. So maybe I'm maybe jumping ahead or maybe going off into the weeds a little bit here,

but how does this work with the STL parallelization initiatives? That is an excellent question. And it's actually an open research issue. I don't actually know, I don't have an answer for you. And it's something that I would love to figure out because I think it's super important. And before any of this stuff makes it into the international standard proper, I think we need to sit down and figure all that stuff out. It's very interesting because, you know, take for instance like a join view, something that takes like n vectors and makes them look like one great big range. You know, if you wanted to sort this thing in a parallel sort of way,

well, you'd want to break it all up and sort each of the vectors in parallel and then do a merge of all of those so so your parallelization can be optimized by knowing about the segments uh in your joined view so ideally um the parallel algorithms would know about the ranges and vice versa so it really like we have to do some thinking to figure out like what exactly are the primitives? How do we hook these two things together so that they know about each other and can take advantage of an underlying structure of the data? Since you brought up performance, Jason, maybe we can talk about performance a bit. What kind of impact do you expect ranges to have on compile times or runtime performance?

I don't expect runtime performance to be affected at all. In fact, if anything, it lets you do a whole lot of really complicated stuff without having to erase types or do dynamic allocation. So in that sense, I think by expressing your ideas at a very high level using these sort of primitives that compose well, you can get really good performance and do really sophisticated things without incurring any performance hit at all. That's really cool. Compile times, when you're composing these operations, you're instantiating templates. So to the extent that template instantiation in C++ can be slow,

then you might end up seeing some compile time hits for code bases that use, intensely use ranges and range adapters. But I don't really expect to see it become a problem because I think, you know, ranges, it's kind of like, you know, seasoning. You sprinkle a little bit of ranges here and there in your application.

I don't expect, like, people to be using this, like, really, really so heavily that compile times will be a problem. I want to interrupt this discussion for just a moment to bring you a word from our sponsors. Do you spend half your programming time finding and fixing errors? Is printf

your default go-to when you encounter a bug? At Undo Software, they know that debugging C++ can be hard. That is why their next-generation debugging technology for Linux and Android is designed for C++ users and is powerful tool for debugging. to find the root cause of a bug. Use watchpoints to reverse continue straight to the time a variable was last changed. Memory corruptions, resource leaks, race conditions, and hard-to-find bugs can now be solved quickly and easily.

Visit undo-software.com for more information and start fixing bugs in minutes, not weeks. Okay. So how long have you been working on the Ranges project so far? Well, it depends on how you define it, really. So I wrote a blog post in 2013, I think October 2013, which really kicked off my current ranges kick. So that's over two years. But range is a topic that's interested me for quite a while.

I had a range library that I wrote back in 2005. You know, there was a boost range library, and it was boost ranges V1, which was really, just really bare bones. There was just these sort of range algorithms and the begin and end free member functions. And that was it. That was the only thing that was in the range library. And I thought, geez, what a waste. I mean, this idea could really go quite far. And we have this boost iterators library. And I got the idea for the range adapters and the piping syntax to compose things. And so I put that together. I called it RangeX because I'm not very good at naming things. And made it available to people.

But I felt like there was something about the ranges abstraction that I was missing. Like I didn't really have a solid grip on it. So I never really finished ranges. I kept waiting until I had an aha and the aha never came. And then I moved on to other things. A lot of those ideas ended up getting merged into boost range. It became boost range V2 and it picked up all of the adapters that I had written. And so like that was good enough. When C++11 came out, Boost Range no longer seemed good enough to me because it didn't account for really important

things like move semantics. So in 2013, I thought, well, you know, this is a simple weekend hack. I'll just make, you know, rewrite boost range and add like move semantics to it, awareness about move semantics. And then I, you know, got to thinking about this or that, and I had a couple of ahas that I, you know, had been a long time coming. And, you know, one thing led to another, and all of a sudden I was re-implementing the C++ standard library. And that was two years ago. And I've been going ever since. And last year was, about this time last year, was a real turning point in my project because it no longer was a side project. I presented it to the C++ standardization committee and they flipped out. They loved it. They wanted it yesterday. And they even were willing to give me money to continue doing it, doing it full-time, which was great because I'm a consultant and I can actually do that.

So I basically fired all my other clients and threw myself into all of this work for the committee, and that's what I've been doing ever since. So it's been about basically a year. Is that correct? It's been basically about a year since I've been doing it full-time, two years since I was doing it off and on. You just brought up the standards committee, so let's talk about the standardization process and how Ranges is looking for the standard. Right. So for those who don't know,

all of this stuff is implemented in my Range v3 library, which you can find on GitHub. So I have a really big range library on GitHub. And for the standardization, I had to figure out a very minimal subset that I could actually get through the committee in a reasonable amount of time. So for those who don't know, getting things through the committee in a reasonable amount of time. So for those who don't know, getting things through the committee means writing proposals and specifying things extremely precisely

in very, very nitpicky, standardese language. And to make my job easier, I had to cut off a very small piece and propose it. So what you can find in the ranges proposal, and I forget the number of the paper, but if you Google for C++ extensions for ranges, that's the magic phrase, then you'll find my paper,

and you could find a very detailed specification for a subset of my range library. And that was in the most recent committee meeting, which was in November in Kona. That paper got turned into what we call an initial draft or working paper for a technical specification. A technical specification, you can kind of think of it as kind of like a standalone standard, something that ships alongside the official C++ international standard. So these things are, you know, as they're separate, people who ship compilers and libraries, standard libraries,

they don't have to implement technical specifications if they don't want to. They could still call themselves standard conforming and not implement the TS. But everybody implements the TSs. So once it actually becomes a final TS, then we can start seeing companies like Microsoft and tool vendors like GCC and Clang to start developing and shipping their own versions of the ranges TS.

And like, how close are we? Well, we just voted in like the initial working draft, and now we're going to beat on it until it comes into shape. And then we will vote on it to be an official technical specification. That could happen very fast, actually. In fact, there are some people who are talking about calling it good and done at the very next meeting, which would be in February. I think that's quite aggressive, but I think it's not unreasonable. I think at the very latest, it would be the meeting after that, which I think is in June or July, I forget. But we're talking about having a final ranges technical specification sometime next year, probably early next year.

So then at that point, you would expect the compiler vendors to have it available relatively shortly after that? Yeah, I would expect that the technical specification would be available in your compiler toolkits pretty shortly after that. Interesting. Are the technical specifications tied to a specific version of C++? Like, would the ranges TS be tied to C++ 17? Yes, good question. The technical specifications are generally, you know, they have a base document,

which would be some version of the international standard. My ranges technical specification is going to need concepts. So it will need both C++14 and the concepts TS in order for you to actually use the ranges stuff.

But the concepts TS is now final, and people are now starting to implement and ship concepts. For instance, GCC mainline, GCC trunk, has a concepts implementation. I don't know when Clang is getting concepts, but I know the Microsoft guys are working on it too.

Okay, so if I'm understanding that properly, you can have a C++ 14 conformant compiler, not have 17 yet, and be able to get ranges and concepts to us. Is that right? Yeah. Yeah. That's the idea. But also, conversely, it's possible that a c++ 17 compliant

compiler would not have those since they're only ts's and not part of the actual standard correct okay okay i'm making sure we got all right we're good you got it you got it all right yeah again concepts and and ranges are just technical specifications, so they're totally optional at this point. So how did you develop ranges without having a compiler that had concepts if it requires concepts? Yeah, that's a great question. The first thing I did when I was writing my range v3 library was to write a concepts light emulation library so uh you can kind of fake it in c++ 11 with um uh generalized sphena for expressions um so that's a very arcane um feature of c++ 11 which is basically you can put any expression that you want in a decl type to find its expression.

And if that is in a function template return type, then if that expression doesn't make sense, like doesn't compile, then that function overload, it's as if it doesn't exist. It's not a hard error. It's just as if that thing doesn't exist. And the presence or absence of that particular overload can be detected, and you can actually do useful things with that information. So you can kind of use this as like a backdoor to figure out whether certain types have certain properties, and you can build a concepts library out of that.

And that's what I did. And so the range v3 library actually uses concepts kind of sorta. And then we started writing the ranges TS without a real implementation of concepts to test it on. So we actually got quite far into the ranges TS work without actually ever testing any of it. Like, we didn't even know if our code compiled. Oh, no. But we had my ranges V3 concepts emulation layer that we could kind of sort of test it

in, you know, this sort of artificial environment. When GCC went and implemented concepts, we actually had a chance to implement our ranges stuff and found that, by and large, it really just worked. We found more bugs in GCC than we found in the ranges like TS. And we found a lot, actually. A lot of GCC than we found in the ranges like TS. And we found a lot, actually. A lot of GCC bugs. And some ranges TS bugs, but not as many

as I expected. I was quite happy. Definitely would be gratifying, I can imagine. Yeah, totally. It's been immensely satisfying, and it's wonderful to see it come together. A guy I've been working with his name casey carter uh has been doing a bang-up job actually implementing uh the ranges technical specification in concepts and you could find all of that code also on github and the github

repo is called cmc stl2 cmc are his initials and stl22, obviously the second version of the STL. So CMC STL2 is where you could find all of this stuff. And if you have GCC built from source, then you could actually compile it and use it. And it's got concepts and everything. Cool. Since you brought it up, what changes are actually being proposed for the STL2? Can you go into that at all? STL2 doesn't really exist.

It's just what we've been calling the ranges TS work. We have this vision that it's going to form the core of a re-implementation of the standard library. That hasn't actually been like officially decided on. Um, I think it's, it's more, uh, a fantasy of, of mine and Casey's at this point, but, um, a lot of people, uh, on the committee, uh, are also kind of, uh, working under the assumption that this will happen at some point. And the reason why is because concepts is, um, is bringing a C change to C++. And in order to properly integrate concepts and concept checking into the standard library, things will break.

Not a lot of things, necessarily. But some corner cases, we're just not going to be able to keep them working because the STL was specified in the absence of proper concept checking. And so things are really quite loosely specified in the STL, which means that there's an awful lot of wiggle room and people took advantage of that wiggle room to do really questionable things. Highly questionable. And we don't want to continue supporting that stuff. So there's definitely some things that we um we're going to lose support for uh when we add concept checking to the standard

library and nobody on the committee likes breaking working code so rather than breaking working code um the idea is uh just start over uh and ship something alongside the old. And that's safer. It gives people a chance to migrate to the new stuff on their own schedule without breaking anybody. And I think that's probably how we're going to see things evolve. Have you been... Go ahead. Go ahead, Jason. I think we have the same question. Maybe. Have you been following along with Scott Meyer's recent proposal that we start deprecating parts of C++ and be willing to break a few eggs and use automatic conversion tools to keep things moving? I haven't been following that proposal very closely, but I think it's an interesting proposal. And now that we have tools like Clang, I think there are definitely people on the committee who are more willing to entertain the idea of breakage,

so long as an automated tool can find those breakages. And as long as those breakages are noisy compile-time breakages and not silent behavior change breakages. Those are evil and nasty, and we avoid them at all costs. So in your ideal world, would you deprecate the STL as it stands and move to just a ranges-based implementation? No, no, no, absolutely not. the current STL unnecessary, then I'm sorry to have given you that impression. Ranges are actually a very thin layer on top of the existing STL. So we're going to have all these same abstractions that we did.

We're going to have iterators. We're going to have algorithms that accept iterators, just like always, in addition have algorithms that accept iterators, just like always, in addition to algorithms that accept ranges. So a lot of the code that you have today, once we have STL2, you'll probably just be able

to change a namespace or a namespace alias, and your code will continue working. You will just have the benefit of concept checking, and you will be able to use ranges when you want to. That's it. So apologies if I scared anyone. So looking into the future a bit more, what other features do you think C++ really needs? Well, I mean, aside from what we've been discussing,

like modules, concepts, ranges, and, you know, a package manager, you know, I think if C++ got those four things, I think we'd be in really, really good shape. The other thing that would be nice to have, I think, you know, as far as language features, you know, because if we're talking libraries, I could go on forever. Language features, like really good reflection facilities, would be really nice.

That would be near the top of my list. To be able to automatically generate things like serialization from lists of data members, That would be really nice. I like to do crazy things like manipulating my program AST as the program is compiling, so that I could implement something like the range-based for loop as an AST macro. You could do those sorts of things in, you know, languages like Lisp or, you know, Dillon.

Not so much in C++. C++ has a very complicated AST, so it's hard to imagine what such a facility would look like. But, you know, I think it's an interesting avenue of investigation, and certainly we don't have to get all the way there to get more simple reflection facilities, just like being able to iterate over the members of a struct and emit serialization routines. That would be really neat. Okay. Jason, do you have any more questions?

No, I don't believe so. Okay. I know you're working full-time on ranges now. Is there any possibility for people to contribute to the project in open source? Absolutely. So the ranges proposal itself is open source in my GitHub STL2 repo. So feel free to hack the LaTeX source if you're so inclined. It takes a certain kind of masochist to hack LaTeX sources. But if you're interested in hacking the source code for Casey's STL2 implementation, that's, like I said, Casey Carter's CMCSTL2 repo.

If you are using RangeV3 and you find a bug and you want to submit a patch, I'm more than happy to take it. And yeah, that's where the action is going on right now, those three repos. So I certainly encourage people to contribute. That would be great. Great.

And where can people find you online, Eric? Oh, well, they can find me on GitHub. They could find me on Twitter. My handle's Eric Niebler. They could find me hanging out sometimes on Stack Overflow. My handle's the same there. I always use my name as my handle everywhere I go. I Reddit sometimes in the CPP subreddit.

And I've got a blog, ericneibler.com, which is, I've been so busy that I haven't actually been writing blog posts, sadly. Hoping to get back to that. I've certainly got a lot to say. Very cool. Well, thank you so much for your posts, sadly. Hoping to get back to that. I've certainly got a lot to say. Very cool. Well, thank you so much for your time, Eric. All right, great.

Thanks a lot, Rob. Thanks, Jason. Thanks for joining us. Yeah, cheers. Thanks so much for listening 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 that also you can email all your thoughts to

feedback at cppcast.com i'd also appreciate if you can follow cppcast on twitter and like cppcast on facebook and of course you can find all that info and the show notes on the podcast website