CppCast - Boost Outcome

Episode Date: May 25, 2017

Rob and Jason are joined by Niall Douglas to talk about Google Summer of Code, Boost and his proposed Outcome library. Niall Douglas is a consultant for hire, is one of the authors of the proposed Boost.AFIO v2 and Boost Outcome, he is also currently the primary Google Summer of Code administrator for Boost. News C++Now 2017 Report Error Handing in C++ or: Why You Should Use Eithers in Favor of Exceptions and Error-Codes JavaScript/C++ Rosetta Stone CppCon 2017 Call for Submissions Niall Douglas @ned14 Niall Douglas' blog Links Google Summer of Code Boost.Outcome Boost.AFIO v2 ACCU 2017: Niall Douglas "Mongrel Monads, Dirty, Dirty, Dirty" CppCon 2015: Niall Douglas "Racing the File System" CppCon 2016: Niall Douglas "Better mutual exclusion on the filesystem using Boost.AFIO Sponsors Conan.io Hosts @robwirving @lefticus Better C++/Chicago

This episode of CppCast is sponsored by JFrog, the universal artifact repository, including C++ binaries thanks to the integration of Conan, C, and C++ Package Manager. Start today at jfrog.com and conan.io. CppCast is also sponsored by Pacific++, the first major C++ conference in the Pacific region, providing great talks and opportunities for networking. Get your ticket now during early bird registration until June 1st. Episode 102 of CppCast with guest Niall Douglas, recorded May 24th, 2017. In this episode, we talk about the recent CPP Now conference. Then we talk to Niall Douglas about his Boost Outcome Library proposal. Niall tells us about how outcome differs from std expected and the process of submitting a fundamental library to boost. Welcome to episode 102 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, welcome back. Welcome back. Yes, it's been a little while. It feels that way, doesn't it? It does, although we did record a little intro just only a week ago. That still feels like a long time. So how is CPP now? It was good. It's always good. It's a great conference to go to. Lots of interaction. There's a report from Odin Holmes that I think we should link to in the show notes that I think was a good take on really what that conference is about also. Yeah, we can definitely put the link to that in the show notes.

And I also got Ben Dean's trip report, which we can talk about in a minute. Yes. Okay, but first, at the top of every episode, I'd like to read a piece of feedback. This week, we got a piece of feedback from the recent Build episode that I did. This is Matt tweeting to us. Great episode of CppCast detailing the C++ highlights at build 2017.

Makes me give a second thought to Windows. He also wrote the interview with Kenny Kerr talking about exposing C++ ABIs to C Sharp was very interesting. Also a Fedora subsystem on Windows. Holy smokes. So yeah, I'm glad you enjoyed that episode, Matt. I felt

really odd doing it without you, Jason, but I'm glad the episode turned out okay. I guess I'm glad it turned out okay also. Yeah. And we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Niall Douglas. Niall is a consultant for hire, one of the authors of the proposed Boost AFIO v2 and Boost Outcome. And he is also currently the primary Google Summer of Code admin for Boost. Niall, welcome to the show. Hi, guys. Great to be back. And thanks for bringing me on at such an auspicious time. Yeah, it's been a while. You were first on at episode 15.

Was I? Yeah, that was a long time ago. That's a very long time ago. Because I've been listening to you guys on and off as time presents over the last while. It didn't seem like 100 episodes had gone. Wow. Yeah, and considering we've missed a few episodes here and there, it's probably literally been 100 weeks, I'm thinking.

Yeah, probably pretty close to it. That's two years. Yeah. I'd like to say I don't feel it, but I do. Well, it's great to have you on again. So we'll start talking about your new library, Boost Outcome, in a little bit, maybe a little bit about AFIOv2. But first, we just had a couple articles to go through.

Feel free to comment on any of these, okay? Sure. So this first one is a C++ Now trip report from Ben Dean, who we've had on the show recently, and who gave a talk with you at CPP Now. Right, Jason? Yes. The talk went well. That's good. So he

goes over the keynotes and then a couple select talks that he went to. I'm interested in if you agreed with his take on the keynotes. He definitely thinks the Haskell keynote was the best one, and he didn't seem too impressed with the D keynote. Well, I think what I will say is, in my opinion,

the Rust keynote was the most persuasive. Okay. In persuading you to try out Rust? I mean, persuading people to try out Rust. I feel like he did a good job of just focusing on what Rust's strengths are and not a whole lot of time trying to directly compare Rust to C++ or anything like that. I think it was well-received by the audience. And based on the kinds of questions people were asking, they were very interested to know like details about object lifetime and how's that handled and where the

overhead comes into play and what kind of generic programming is available and stuff like that. Okay. What were your thoughts about the, the D keynote and the Haskell one? Um, I didn't see all of the Haskell one, I believe, because I was thinking about my own talk that was coming up, you know, that, that goes that way sometimes. And, uh, the D one was good. And, uh, Ali stuck around for the entire conference and had lots of interactions with people outside of the keynote. And I think those were, were,

were very well received and, uh, and persuaded other people to give D a try also. Okay. And did you attend any of these other talks that Ben is talking about? I went to Charlie's and David's and, uh, Phil's. Yes, I went to three of the four that he talked about.

And they're all fun. Charlie is actually going to be reprising his talk at our meetup on June 1st. So anyone who's listening who's from Denver and you haven't joined the Denver C++ meetup, go join it and you can come see Charlie's talk. And this is a talk on system error, which is a feature we really haven't talked about on the show before, as far as I know. No one talks about it. I mean, like, even people

who, shall I say, have been involved in the standards process who were at the talk were just unaware of what's in that header. It's like the overlooked header. Do you use this one, Niall? You must in AFVIO, I'm guessing.

Well, actually, this is the whole point of outcome. So myself and Charlie collaborated extensively on the development of my CCU talk and his C++ Now talk. He actually pared back what he presented quite heavily from what he was originally going to present, which was going to be much, much bigger. I think he had only 300 slides or something in his one. A little over 300, I think, yeah.

Yeah, I know. It was going to be a lot, lot bigger. Because once he started down that rabbit hole, it just kept growing and growing and growing. And he ended up only giving the first chunk of it in total. So it actually worked out really nicely, because my ACCU talk ended up following on from what I understand from what Charlie's told me. I haven't actually seen Charlie's talk because I wasn't in Aspen. But I understand that it

follows on from where he kind of finished. So he really began to get into the material that I covered. And then of course, you see, my talk was only the first third of the talks I'm doing. So for a meeting at C++ in Berlin, I was going to try, I submitted the second part of the talks I'm doing. For a meeting of C++ in Berlin, I submitted the second part of the three-part talk. So the thing is, it's weird.

You're right about a lot of the people on the committee either know a terrible, huge quantity about system error, or they know nothing about it at all. And it would be the majority know nothing about it at all. So in my talk, we had quite a few members of the standards committee who afterwards said that they found it really clarifying, because it just had system error they knew about, but it was kind of this fuzzy thing off in the corner that you don't tend to think about too much normally. So, how that will get taken into C++17 and beyond

is going to be interesting, I think, for everybody, actually. I need to go back and watch your talk then, and hopefully, with any luck, I think, for everybody, actually. I need to go back and watch your talk then, and hopefully, with any luck, I guess, see your talk in Berlin live, and then I'll have seen several parts. This is assuming, of course, that it gets chosen to be presented, so it may well be that Meeting C++'s review

committee decides that that talk is not suitable, in which case I'll be there anyway, so I'm going to take the entire family with me, like I do to most of my conferences, so I'll be there with little children running'm going to take the entire family with me, like I do to most of my conferences. So I'll be there with little children running around, and we'll see how Jens copes. I'm sure we're fine. While we're on the topic of system error, this next article we have is error handling in C++, or why you should use ethers in favor of exceptions and error codes.

And this is not really a concept I had read about before, ethers, but I'm guessing it's something you're familiar with, Niall. Indeed. So Outcome implements a set of ethers, or eithers, depending on which country you come from. And it would be certainly the flavor by where the C++ future standards, so the Library Evolution Working Group, which is coming up with a standardized formulation of this.

So it's not the type of either or either, which is covered by that article. So one of the things that was interesting in that article was that he actually went into Boost Expected, the old 2013 library, era library, which has been abandoned, as far as I'm aware, for at least a year. And the current Lugue reference implementation

is based on that library, but is quite far away from it now. So it was slightly frustrating to read through that article because it was a little, from my perspective, a little stale. On the other hand, looking at the Reddit feedback, a lot of it was very new to a lot of people, so that was good.

You know, there's an interesting note. His actual link to Boost Expected, if you click on it, takes it to your Boost Outcome. Oh, dear God. Really? And I had never even thought to check that. It's really interesting because, of course, Outcome does not provide a Boost colon colon Expected. It's really interesting because, of course, outcome does not provide a boost colon colon expected.

It's funny. It's actually a boost colon colon outcome colon colon experimental colon colon expected. So, oh dear, my documentation must be really bad. Interesting. Okay, this next article

is the JavaScript C++ Rosetta Stone. And this is actually just a markdown file on GitHub, where the author, who I guess is primarily a JavaScript developer, is showing how you can implement some of the features of JavaScript in C++. And I thought this was pretty interesting, doing things like comparing dynamic typing with the use of variant or any, and going into some of the weirder JavaScript features and showing how they can actually be implemented pretty simply in C++. What did you guys think about this one?

Yeah, I thought it was interesting. I thought the objects block was the most interesting to me, where he says he thought that JavaScript objects were kind of magic until he realized that they're just not. Yeah, I thought the other thing that struck me the most about it was just how far modern C++ has come in terms of catching up with the simple syntax that you had in a lot of the interpreted

languages. I mean, of course, that's where we're going next with the ranges TS. You're getting a lot of that Python succinctness and functional programming and list comprehensions built in once that enters the standard. So we kind of lag and we track behind a lot of these other languages by about 10 or 15 years, but we get

there eventually. And it's really interesting reading that article, you know, if you went back 5, 10 years ago to do the same things as he shows in really short bits of C++, you'd have to write an awful lot more, you know, in C++98. So it's kind of, you know, illuminating in that sense. That made me stop

and think. Okay, and this last one is CppCon 2017. Call for submissions and registration is now open. So obviously this is a big announcement. 1C++ Now is done. CppCon is kind of the next big conference, at least for the U.S. Jason, have you submitted anything yet?

I have not. Our listeners should be aware the submission deadline is short june 11th is the deadline and when this airs uh that will be about two weeks i guess yeah so we you know get your submissions in i have a couple of ideas planned and also your meeting c++ submissions are actually i think required sooner niall do you recall the data is uh i think it is the first of june yes so get your conference submissions in they are all coming up and they're all fun to go to yeah so by the time this episode airs that's less than a week to get into meeting C++

and just about two weeks for CppCon. Yes, it's on my to-do list literally for today to get both of those submissions in. Wait until the last minute, huh? You know, I had to get one conference out of the way before I could start thinking about the next one. Or the next three, as the case may be. My first year not at CPPCon in some years,

so I will be skipping it this year. That is due to a new baby turning up exactly during the time that I'd be preparing the material before submitting the call for papers. So I had nothing to present. I had no new material at the time, so there was nothing I could... I mean, I could rehash something old, but then I could just take a break this year

from traveling all the way to Seattle. So I just thought to myself, no, I'm taking it easy this year, so we'll see what happens. Sounds like you have a good reason. Okay, so... Oh, go ahead. While we're talking about conferences, the deadline for early bird

tickets for Pacific++ is also coming up in the next week. Right. So make sure you buy your early bird ticket. It saves you a couple hundred dollars. And early bird tickets, are they out for CppCon as well? I don't know. It says registration is now

open. I think there's usually an early bird period. Let me see if I can find this really quickly yes uh june 7th the july 7th excuse me is when that runs out okay and we should mention again that there's a lot more of the um pre-conference uh tutorials including one from you jason right uh actually i will be doing post-conference, two-day talk on C++ best practices, two-day, excuse me, training on C++ best practices. So there's some two-day trainings before the conference,

some two-day trainings after the conference, and then there's a couple of training that's like one day before and one day after, something like that, I believe. But there's a lot of offerings for training for this year, and so everyone should come to mine. That's quite unusual by most conference standards, isn't it? I mean, ACCU has one day, so does CPPCon,

so I'm surprised that the two days before and after, that's an unusual quantity of training. Yeah, we'll see what happens. This is, I believe, the first year where there's training afterward, but there's a lot of people who are interested, I guess, in doing training, so we'll see how it goes. Cool. Okay, so Niall, maybe to start off,

we can talk a little bit about the Google Summer of Code program and what exactly the relationship is there with Boost. Oh, yeah. So this is my last year's primary admin. So I've done four years as primary admin, and I intend to resign after this summer. So next year, I would serve as backup admin to whoever takes over so we can pass the torch. And then after that, my service is done. So I believe very strongly, especially for volunteer roles, that five years is a reasonable period of time

to be in a place and it's time to move on and make way for fresh blood. So no, the last four years have certainly been eventful. We were up to getting in lots and lots of projects and then last year Google rejected our application out of the blue,

and best of all, for no good reason. So they simply said, you've had too many GSOCs of late, so we're giving you a year off. Come back next year. So last year, thanks to John Kalb and Bryce, and especially IMC Capital Markets, we managed to pull together enough money to fund Google Summer of Code with our existing

students as a boost Summer of Code to tide over the projects that we're running. And we're really glad. We only could do three, unfortunately, but it was better than nothing. And then this year obviously, because we got rejected last year, finding mentors was nigh on impossible. So this year we had a very very reduced

Google Summer of Code, we've only had three projects and indeed I'm mentoring one of them myself and hopefully we'll be able to build that back up again as a rolling force, but it won't be me who does it it'll be whoever takes over next year so it was certainly a rollercoaster ride and I

very much enjoyed my time, it was hard work at times as well, but I hopefully brought something to which wasn't there before in terms of upping the caliber of students we had because beforehand we were a lot looser with who we brought in now. I mean the students are seriously

impressive programmers almost entirely. My student this year he just keeps surprising me in terms of stuff he knows that I did not know at his age. It kind of makes you feel, I can feel that age

creeping onto me, where these younger people, they're running rings around me. That's okay. It was the same with Louis Dion, who came along with Hanna, which was a Boost Summer of Code project originally. That was just such a phenomenal project which of course is now a Boost library and indeed parts of it look like they're going to go into the standard

currently, so they're on standard track so it's amazing, I mean I don't know if you saw or heard about the Herb Sutter's Metaclasses proposal which he sprung on everybody at the end of ACCU and a lot of that relies heavily on what Louis has been proposing for

constexpr lambdas, and where they're going to go with that. So out of hand came that stuff, which is then being built on by Herb to propose these metaclasses, you know, so it's just this... I'm glad that Google Summer of Code could have had such an important influence,

and thanks to Google for giving us all that money, you know, without that cash in place, none of that would have ever happened. You know, I think a lot of our listeners are open source project maintainers. So I'm kind of curious, just like, how does the Google Summer of Code process work in general? Oh, I knew you were going to ask that.

So last night, I was spotting up on this because, you see, it's all changed. Oh, that. So last night, I was spotting up on this because you see, it's all changed. So it was the way, under Carol Smith, it had run a certain way for many, many years. And then Stephanie Taylor took over two years ago and has changed so much for the rules and regulations and the procedures. And indeed, my student asked me last night, when do I get paid? And even that's changed. So I was having to look it up. I'll try to answer, but just don't trust anything that I say.

So the idea is that students now put in proposals into the Google Summer of Code website. We have a line of mentors obviously available and we try and match up super mentors out of the Boost community with student proposals. We've been increasingly of late trying to encourage mentors to write the proposals first

and get students to attach themselves to them rather than students necessarily innovating on their own. We find that it's much easier to raise mentors for that particular way around. And once you've got that, you get them in. There's a competitive process for the number of slots that Google are willing to fund, which may be a subset of the number we ask for, or maybe not. And then we then have to manage the relationship between the students and the mentors over the summer, and hopefully at the end of it, some useful

code pops out. Generally, at Boost, we've had things a lot easier than most other Google Summer of Code organizations. So they have problems with students disappearing or mentors disappearing and all that sort of thing. Certainly during my tenure, we've not had

those sorts of problems. I'm really glad about that. I think that the professionalism we have in C++ and that wider boost area has been hugely important to everybody. We just get stuff done. Go ahead, Jason.

Sorry, Rob. I was going to ask, could you tell us a little bit about the students who are involved in this? Are they comp sci undergrads or graduate students? How much experience do they already have when they're doing a cool Summary of Code project? It varies, actually.

A lot of them will have been programmers who are self-taught and were programming from, you know, six or seven years old. So they kind of came to this. And some of them are not even actually doing a computer science degree. So you'll find people, I mean, Louis, for example, was actually not a programmer. He was actually a math student, if I remember rightly. And he came to, when he did his compulsory programming part,

he sort of went, ooh, I actually like this much more than maths, I think. I'm speaking for him, but I don't know for sure. But my memory says that that's the case. And he was writing out this lovely, you know, constexpr programming code with generic lambdas and all of this sort of stuff, basically off the bat. And you're

kind of going, wow, you know, just goes to show you what a keen mind can do. You know? So you don't have to spend years training yourself into C++ at all. You don't need that 10,000 hours and that. Get going after 40, you know. So, no, I think really exceptional students have that ability. They're very rare, though. Very, very rare individuals. Most of the students there have been programming since they were very young. Some are conversions off physics or off maths. Some are in just straight computer science courses. There's a mix. But in terms of their

age, I have found that since we brought in the programming competency tests that we tend to be selecting post grads more than undergrads whereas previously it was more undergrads rather than post grads. But equally there's been process changes with Google. So Google used to pay $5,500 to everybody

irrespective of where you're located in the world and And obviously that's a fortune of money to some people in some parts of the world, but it's peanuts to other parts of the world. So just there this year, maybe last, they introduced purchasing power parity adjusted values. So now people in poorer parts of the world only get $2,000 and people in richer parts get $6,000. So that's changed the mix of students that we've received. We're not getting the kind of caliber that we used to get from, especially places like India, is noticeable, because they've got Facebook and they've got, you know, Google all offering them summer internships,

and they're just snapping them up, you know, over in India, and we're not getting them like we used to. So maybe that's deliberate, of course, by Google, that they changed the funding to make that happen. I honestly don't know. That's very interesting. It is. It is interesting. You never know why Google

make these decisions. Of course, they don't say publicly. And in the end, it's them who's funding it, so they can choose whatever allocation strategy suits them. Yeah, it's their money. Indeed. Indeed. I think you kind of mentioned this, but students

come up with their own ideas and petition for this funding? Well, this is certainly what's supposed to happen. Students are supposed to come up with their own ideas. We have found in the past that generally students aren't sufficiently familiar, especially with the contents of the Boost Labs, and they end up proposing something that's already in there, or even in the C++ standard library, almost inevitably. 80-90% of the time, they'll propose something that we

already have. As a result, we've tried to argue that it's better for the mentors to come up with ideas, or the community to come up with ideas, and kind of get students to be focused and directed towards that instead. So a lot of the libraries will have some work that they need to do

on existing code to extend it in some particular way, and the proposals that go up, for example, Boost UBLAS, David Bellow every year is a regular guy looking for students to help him write more code for UBLAS, which does matrices and other such mathy things. It's not my niche, I'm afraid. The other one is Boost Geometry. They also do matrices and mathy-type things.

I actually don't know there either. But certainly those two projects are regular, very, very regular for getting students in to help them out, write more code to implement more math-y type things. And, no, it's... I think at Boost we're a bit different in that sense. Most students, of course, are not taught C++ at university anymore. They're taught any language other than C++. So their familiarity with the standard library

tends to be a lot more shallow, especially with the Boost libraries, than, say, it would be with Java, for example, or.NET, or even Python increasingly. So this guided approach is what we feel works best. There are some who feel that we don't give enough scope to students to own what they do, but that's where I would hope that as org admin I try to facilitate more student involvement in the design of things and allow it to be a bit more organic than it could necessarily be.

But it's a tough call. The trouble is, you have to bear in mind a lot of the Boost developers have 10, 20 years of experience behind them and they really do know their stuff and if they say the work needs to go here and not on redoing this

entire thing, then they're usually right. In fact, they're almost always right. It's interesting because Louis Dion actually, when he came on along with his first proposal, I remember trying to get dissuade him from it repeatedly and then I saw a talk by him at C++ Now in Aspen where he was showing all of the different ways that he

had benchmarked all of the different strategies for implementing something that was going to eventually become HANA. And then I went and asked this student, he's carte blanche. He can go ahead and invent anything he wants from scratch, because he really doesn't know what he's doing, you know. And moreover, he'd done the empirical groundwork to determine that this library should look this way. You know, and that's all we're really looking for. I mean, if you can come along and prove that we're wrong, we're wrong, and we'll work with you, you know. But it's a very rare student who will

do that pre-work effort. That is good that you are willing to be proven wrong. Well, I would like to think that's the case. A lot of people on Reddit say that is never the case with me, personally. But I try to ignore them. But no, I would like to hope that I've tried to encourage within the Google Summer of Code program, that from both mentors and students. I mean, some mentors in the past have come very much from, I am an old, experienced person, and you, the student, are the vessel into which my knowledge will be poured.

That's not really something that millennials do nowadays, to be honest. Millennials very much take the view that it is they who need to teach the old people something. And I actually think that there is a balance between the two, which is mutually beneficial for all, as someone who is halfway between being old and being a millennial. So that's where I try to reach. But it's a tough balance to walk sometimes. And whoever comes to the next org admin is going to have lots of fun.

Do you know who's going to be taking up the program now? No, it's a free election. So I had said to John to... So basically the way the Boost gets run is that at C++ Now every year, which of course used to be BoostCon, they still organize Boost in their face-to-face meetings, so they have a big town hall type meeting on Thursday

night, if I remember rightly, and they do a carve-up of all the different positions to do with Boost and with the steering committee and the general organization getting things on. And John will basically detail the successes from the previous year and what needs to happen next and the financial situations and so on and so forth.

So my assumption is, and I only based this on years gone by because I wasn't there this year, that he will have asked, he will have said that I resigned. He usually then will say that everyone should give whoever it is who's standing down an applause for the service they did, and then he will say who wants to stand for this position. So I haven't found out yet who did or if anyone did. Obviously, I really should get around to that. I've been a bit busy with the outcome review, which is currently ongoing, I'm afraid,

so I hadn't actually thought of it until just now. And I did not go to that meeting, so I can't give you a preview of what happened. Arse. Well, you just mentioned the Boost.com library. Do you want to tell us a little bit about that? Oh, my. Yes. So, yes, right now at the time of us recording this, the outcome, sorry, the review.

So, actually, I should probably explain. Boost accepts new libraries through a process of peer review. So what you basically do is you put together a library, you put it into the review queue. At some point, the community will find a review manager who wants to manage the review, and everybody comes along and

decides whether it's up to Boost quality or not. And this is mainly done through a process of oral defense. So people will make a series of observations about the library on the developer's mailing list. You must then defend your choices, accept where you've made mistakes, if the mistakes have been proven,

and sometimes simply say no to people. And that is a thing which lasts for 10 days. At the end of that, there will be a series of people who vote. The review manager then sums up and weights the different votes and comes up with a recommendation. That then may lead to subsequent reviews and subsequent reviews or might be accepted or might be rejected. So my last review was the AFIO review, which would have been three years ago, I think. Maybe even two, three, something like that.

And that was rejected. On the other hand, it led to AFIOv2, which was a complete rewrite and redesign based on the feedback that came. Out of that then came the outcome library, because that was an internal implementation of an either monad effectively, which can be used to implement... How do I get this succinctly? C++ exceptions, they're really great, but they are, in modern implementations, they're implemented using a table. So what happens when you throw an exception is that the runtime

will go off and it will examine for every stack frame running up until it reaches a catch handler. It will look up the stack pointer for the return address in a table and figure out what needs to happen for every single stack frame that has to be unwound. And that's quite a slow process. It takes thousands of cycles per stack frame that gets iterated out. So in that case, if you're a code base that tends to run into errors or failure quite frequently, using C++ exceptions to transport that is a very bad idea. So this is the reason why the networking TS, which is formerly or still is ASIO, and indeed the file system TS, don't do that. They give you the option of returning a thing called a std error code, and that's simply an

integer error code plus a reference to a singleton to indicate what kind of domain or what that error code means. So these are great, and they're a much lighter weight than C++ exceptions, but the great trouble is that they have the same trouble with C integer error codes, in that if you fail to check them, you lose the error, and it's very, very easy to fail to check them. Even very experienced programmers will consistently fail to do it, i.e. I certainly know in my case that I do. So what came along then is what we needed was a transport, which is effectively a variant wrapper

that lets you choose either a positive T state or a negative error state. This is where your either modan is coming in. And then you can mark this up with no discard under C++17 such that if you fail to do something with it, you'll get a static warning by the compiler, and that encourages you to not forget to check errors as they come out. And this is the main value add. It declutters your code, makes hopefully things a lot easier to read, and this is where the standardization effort for expected is coming from.

So they're implementing one of those as well. So outcome originally implemented, it was actually an alternative to the very early boost expected library from back in 2013, which was a huge big monstrosity, huge big complicated library. And I happened to be in a contract at the time

where we rolled it out into a very large code base and compile times just were murdered. So it became clear that we needed something much lighter weight and that did an awful lot less. That's where Outcome originally began. And it then iterated through the last two years of being firstly growing in features

and then being pared back in terms of features to eliminate stuff that wasn't strictly speaking necessary. And then when we kind of got to last January and I was pulling around Reddit to get feedback on the tutorial, which had to be rewritten completely from scratch four times because documentation is really hard. So it became pretty clear that people didn't really want my slight variation off expected, which are these outcomes.

They wanted an actual expected implementation as would be eventually standardized. So I went ahead and rolled one together. So you now get my extended outcomes, and you also get an expected implementation, all using a common infrastructure internally, and in fact, actually a common implementation. And that is thus the library that's been submitted to Boost.

So, so far, so good. It's exhausting. I don't know if users, or sorry, listeners are aware, but most Boost reviews tend to be two, three, four people reviewing it, and very, very little feedback comes back in, because it's such a niche topic that very few people can speak about it. In other words, all the low-hanging fruit has been plucked for Boost, and C++11 in general,

but occasionally a fundamental library comes along, like Outcome or indeed AFIO first time around, where 400, 500, 600 emails in the 10 days is not uncommon. For the AFIO v1 review, it was about 450 emails. The rate we're currently going with the outcome, I think I'm estimating it will be about 600 and something emails will have been sent and received to do with the review. So it's one of those things where I'm really glad I am a self-employed contractor because I can be out of contract while this happens because you literally spend all day long replying, reading, writing email, big in-depth technical email. So that's the

outcome story. And I'd imagine the review will still be on when this gets aired. So if you have any thoughts or feedback, please do jump on board and any reasonable opinion is great. So come along and contribute. With 600 emails, are you getting a lot of duplication of feedback? You get an enormous quantity of duplication of feedback. So the great trouble is that most reviewers will identify the same problems as the other reviewers have, but they haven't read

the previous threads where those people have said it. So one of the things there, I actually got a whole lot of criticism. I've read it earlier today where people were saying that I had a very short temper. And what they don't realize is that when you're responding to the same point for the 20th time,

it can be very hard to be nice, you know. And you try your best to do so, but you have to bear in mind a lot of this stuff is happening at 1 or 2 in the morning by this point after the kids have gone to bed. So your temper sometimes gets a little fray or you misphrase things in a way that you wouldn't do if you were less tired. And people during the review, their experience with this, they've all gone through it before. So everybody within the Boost community knows this. But I think from the outside,

it can look a lot more passive-aggressive than it actually is. So people can go, oh, it's really awful and really toxic. But I mean, compared to past exchanges on Boost, this one's very tame. So I heard two things. The first is you want more email from reviewers, but only if they've read the previous 600 emails.

No, I actually, so long as someone has read the documentation, I'm actually completely happy. So quite a lot of reviews come in where nobody has actually read the documentation, used the library, or looked at the source code. And genuinely, genuinely, so I think I've noticed three bits of feedback that came in where that was the case. People simply objected to the library in principle, rather than having actually looked at any of it at all.

And that is something that happened also with AFOv1. There was quite a few people who came along who had never looked at it at all, who then made a very strong opinion about it and that did annoy me at the time there's no doubt about it so you know again one tries to do one's best but it's a very emotionally tough experience and until you've gone through it

yourself personally it's very hard to appreciate I think anyone who has been through it knows what it's like Michael Case actually was very good and he went on Reddit to say how emotionally demanding it is to go through a view, and I'm very grateful for doing that. That's good. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors.

JFrog is the leading DevOps solution provider that gives engineers the freedom of choice. Manage and securely host your packages for any programming language with Artifactory. With highly available registries based on-prem or in the cloud, and integrations with all major build and continuous integration tools, Artifactory provides the only universal,

automated, end-to-end solution from development to production. Artifactory and Bintray now provide full support for Conan's C and C++ package manager, the free open-source tool for developers that works in any OS or platform, Artifactory and Bintrey now provide full support for Conan's C and C++ Package Manager, the free open-source tool for developers that works in any OS or platform and integrates with all build systems, providing the best support for binary package creation and reuse across platforms. Validated in the field, provide a flexible, production-ready solution,

and with a growing community, Conan is the leading multi-platform c++ package manager together jfrog and conan provide an effective modern and powerful solution for devops for the c++ ecosystem if you want to learn more go to jfrog.com and conan.io so you've mentioned uh boost outcome and the proposed expected kind of that your library implements both but has a common thing but let's talk about actual, like, what's the difference, what are the use cases of these libraries? I guess start wherever you want to. Oh, right, so I'll start

with the narrow, the really, really narrow one, which is simply expected. So expected, the idea behind it is that rather than returning a reference to an error code, std error code, which is the way that the file system TS and the networking TS do it. And I think actually,

recently he was saying that Chrono apparently does it as well, which I didn't know beforehand, but he would know. He's the guy who maintains that library. Instead of having to return these, which kind of messes up the API, you actually have it on the return type. So your return type will always be an expected,

and it'll be a T type for success, the normal value it would have. And your error type is usually defaulted to a std error code more often than not, although not necessarily. And that lets you then more succinctly write your code, and you don't have so much handling of forgetting to check things

like the EC state. It also forces you to write out your logic for handling failure explicitly, so you have to do some if statements because built into expected is a whole lot of undefined behavior if you don't check state before accessing state. So that is a deliberate choice. Do we mean undefined behavior

like in the C++ standpoint, like it's allowed to format your hard drive undefined behavior, or...? It's reinterpret cast. So the expected proposal copies the optional, so std optional is appearing in C++17 where it will do a reinterpret cast

of the observers, so that's all it is is an implicit reinterpret cast. So if you fail to check state before you do it, it is a reinterpret cast of the internal store so you really do get true undefined behavior as in random bytes. Now, a lot of people are surprised that std optional is in the standard and does that. But it is a certain viewpoint which was adopted by the committee of a narrow contract on the observer functions within optional.

I personally disagree with them. I think actually almost everybody has an opinion there. But in the end, the committee had to come up with some common ground that was acceptable to as many people as possible and they came up with std optional as is in the standard. So expected now of course is a problem because they want to maintain an API equivalence with std optional and they also want to have the same semantics as a std variant. So they're kind of sitting themselves in between the two because it is a variant store of either a T or an E but with the API of an optional.

So having to meet both of those, they're adopting the optional narrow contract based approach and it is something that I personally think is unfortunate. But that's why I provided alternatives in terms of things

that look very similar but don't have that problem in outcome so if people agree with me on that they can go use these instead and they can automatically switch between my additions and expected or vice versa as an ad hoc basis because they're actually all the same thing underneath, they're literally identical implementation, they're just personalities

so the way that the library's been designed is that it has a flavour of API with the personality but underneath it's all identical in every way. So the compiler can optimize and tune on the basis that these things are literally identical throughout. Okay. So then I guess you started by saying error codes have this problem that they can be ignored. So how does expected or... Outcome. Outcome, thank you,

prevent you from ignoring the error code? So the big advantage is, because it's a variant store, and your return type, your value type, is bound in with the same object that returns your error type, when you're typing out your code to extract out the value,

which is a.valueObserver function, you're very much more likely to also deal with the error indication. So if you access value and the expected is an errored state, it will then throw a bad expected access exception.

So that kind of forces you to deal with it whether you want to or not. So it does kind of revert to an exception at this point. Only on the.valueObserver. So if you don't want the exception to be thrown, you can use the star operator, which will do a reinterpret cast and therefore give you back always a value type,

whether it's valid or not is a separate matter. But because you're binding it into the same object, you can't forget to deal with the error code because it's there in front of you right now. So when you're typing out your code, there's the place to put your error handling. Your failure handling is right there next to the value extraction point.

And as a result, you tend to not forget it generally. And then, of course, you can also add the no discard modifier from C++17. So if you have a function that returns one of these and you fail to do anything with it at all and just let it go off to void, you'll get a compiler warning on C++ 17 compilers.

So it's marginally better. But in practice, when you're actually writing out large code bases, marginally better can translate into huge efficiency gains in terms of not having problems with bugs, in terms of maintenance costs as much lower, being able to audit the code

is an awful lot easier because you don't have this stuff spelled out in front of you. There's been a pent-up demand for one of these for quite some time. And I think, from what I'm told by senior members of the committee, the chances are good that Expected should make C++20, and if not then, sometime not long after. So that would be cool, because then it would be in the language with everything. Good.

Going back to the review process, how much longer in it? It sounds like you're in the middle of it right now. When will you get a decision back about whether the library will be accepted? So let's see. Today's the 24th, Wednesday 24th. I believe we run through... I think we Today's the 24th, Wednesday 24th. I believe we run through...

I think we started on the 19th, so it's ten days after the 19th, which would make it the 29th? Yep. So the review will end then. Now, as to whether it actually does end then, in the past it has been the case that the review will just carry on right on after that for several days because people still have stuff to discuss. And I have seen reviews in the past, especially about fundamental stuff like this, where it lasts five or six days afterwards and will run into another review.

So you have this weird situation where there's two reviews going, effectively. And then the poor old review manager has to then go through and wade through the entire conversation from start to finish and write it up into a summary of a report. So how long that takes, it can take some weeks uh to come up with something and uh charlie bay who was the person who who presented uh on system error at c++ now has undertaken that role um all i can say is so much gratitude towards him i've reviewed managed two reviews and that this i've never done one of a fundamental library before, and I just

don't know where he's going to begin with the quantity of feedback he has to swim through to come up with a result. So my hat is off to him, and thanks very much. Charlie seems to have a lot of energy if you've actually been to any of his talks, so I'm guessing he'll be able to pull it off.

Oh, I know Charlie well for many years now. We are very like-minded on many things, including especially on the use of ternary logic. And this is one of the things which has turned out to be quite controversial in the outcome review, is that for my extensions of expected T, which is a binary state, so it can either be a T or an E, and a non-valued state is not possible.

So the value list by exception from std variant of C++17 has been dispensed with thanks to some trickery under the hood. Thanks to a Mr. Anthony Williams, who should be familiar to most listeners. So, no, I implemented a tri-bool state. So you actually have three states that my extensions can be in. And this has proved to be quite controversial. So I have an official empty state, which I am defending the rationale for, but a lot of people don't like it on principle rather than anything else.

So it's an interesting debate. Charlie also believes in ternary logic where appropriate, and I would be very similar to his opinion on that. I think it can greatly simplify code, but some people really don't like the notion of a non-Boolean logic. In my own experience, it comes up occasionally, and sometimes it's the right solution. It does make code simpler, easier to implement. I would feel so.

I think a lot of people would agree with that, but they would say you shouldn't have it there unless it's being used, I think is the opinion. I would take the argument that Boolean is a subset of ternary logic, so the tribal way. So you just don't use the third state,

in my opinion, and you should be fine. It's not like it will automatically switch itself into that state randomly, so if you just don't use it, it will never turn up. At least that's my argument. Some would then say that, you know, well, it can because you can actually physically set it. And I'm like, well, you actually have to write out a specific function which actually sets the third state.

So that should never happen. Anyway, that's one of the things. That's an ongoing debate that has now lasted a week. And I'd imagine there's another week left in that debate. And I don't think there'll be a resolution at the end. Wow. You have to bear in mind, fundamentals they're really fundamental, and they're like Boost used to be back

before 2008, when they were still coming up with the stuff that ended up in the C++11 library. All these big, long debates about really big-picture stuff, and the pros and cons of things that don't really have a right answer. You just have opinions of people who are very, very good at this stuff where they just genuinely disagree.

And there is no necessarily right or wrong answer to it. So if I sit down with John Lakers, for example, there's a lot of stuff I agree with him on, but there's also a lot of stuff I disagree with him on. And same if you sit down with Bjarne. There's a lot of stuff you agree with him on, there's a lot of stuff you disagree with him on. And I think that's a characteristic of stuff you agree with them on there's a lot of stuff you disagree with them on you know uh and i think that's that's a characteristic of of when you

get to a certain level of expertise um is that you can reach a stalemate with anybody so if if you don't mind i maybe take a quick aside since you're you're deep in this process and i'm thinking about some of these other languages like we've been presented to at C++ now, where there tends to be like a core organization, if you will, that drives the future of the common libraries and the standard of the language. of a very large design-by-committee almost process going. Do you think this is an advantage or disadvantage? Our language moves slower. Do you think we get better results for it? That's a very controversial question to ask.

I would say that... Well, you can go as political as you want. Well, I would say that back in... Well, what was it? Booster started in 98 or something like that by Beeman and Dave Abrams. And their specific goal

when they came out of a WG21 meeting was that we needed an incubator to test these library ideas before we take the risk of standardizing. And that's where Boost originally began. And Boost kind of slipped away from that mission for a bit for a number of years there.

And what happened then was that C++, the WG21 committee, kind of got reorganized around working groups. And a lot of the new library development kind of moved into library evolution working group and language evolution working group and so on and so forth. And of course that's a much smaller group of people. I mean, the total number of people who attend

most C++ meetings in terms of regular basis is only about 100-120 on a regular basis right around the world as they go. So then the question becomes, is more eyeballs better for good design than fewer eyeballs? Then the question becomes, what's the caliber of the eyeballs

relative to other eyeballs? And it's, again, it's not something with a straightforward answer. I mean, a room full of experts can come up, I think, with a worse design than the masses. And this is something I very strongly believe. I'm a populist when it comes to API and software design. I genuinely believe in giving people what they think they want

as long as it's not too terribly bad for them, which is a certain patriarchal viewpoint as well. But this is not a common viewpoint. It's very common within Python, that sort of ecosystem and that language philosophy and that way because it comes from Guido. But within C++ it's not a common viewpoint at all at all. And it leads

to an increased quantity of conflict certainly historically between me and the more traditional viewpoint within C++. Now it's interesting because if you sit down with Bjarne and you talk to him about ecosystem concerns and where WG21 is really great and where it really falls down and so on and so forth, me and him would agree on a great deal on that stuff. And his viewpoint would probably not be a majority opinion on most of these things.

So in that sense, it's very interesting where on some topics, you can have this huge agreement with other people, and then on other topics, you can, with the same people, be miles apart, you know. And in the wider picture of things, you have to bear in mind that C++ is a very old language.

It has a lot of how it's evolved comes from historical accidents rather than through any rational or productive way of doing things. And I think everybody has agreed with that. I mean, everybody would wish it would be different, but it can't be due to this historical way of evolving things. If you look at how the Python Software Foundation has evolved, that was very much with Guido just constantly saying no, no, no

to events of going in a different direction where he would just drag it, often at great personal cost, away from a direction that he thought was a very bad idea. And he's ended up with where it's at now, which I think is an amazing accomplishment, you know. But it requires a lot of self-sacrifice. It means losing personal money, in the case of Guido, if I remember rightly. You know, he put his own finances on the line

to make it go in the direction that he felt was right. And of course, it's not popular to not do what the majority want you to do at the time. You're always going to get a lot of trouble from it. So it takes a certain amount of bravery and authority within the community to be able to pull it off. And all of these things, when it comes back to C++, we don't have the single points of authority that we once had because it's such a mature language. So once upon a time in the past, there'd be one or two or three people who if they said that this should be the case everyone's

going to go well if they say that's the way it's going to be nowadays it's much much more diffuse you have lots of people who are experts within a very small niche who are recognized as experts in that nation whatever they say it goes but as soon as they start talking about stuff that's outside their particular niche field people then will question them and say, you don't know what you're talking about. It all sort of can get very involved, you know. So, I don't know. That's me being relatively politically correct because we're a public. If you take me to a bar and you get me a few drinks, you'll find I get a lot more literal than that.

But so do most of the people in the community. Everyone has quite strong opinions on this stuff, and things can get quite animated. But that's half the point. That's half the fun of going to conferences and stuff. You meet people and you exchange animated opinions. And I think it's weird because from the end user, from the outside perspective,

it can all look very aggressive and confrontational that we all hate each other. And it's actually, you know, you have to bear in mind, you've known these people for years and years and years, and you've worked with them for years and years and years, and you can dislike someone, but respect them. And that's something I think that is often lost in people,

that there can be a mutual, deep respect for someone else in the community, that you completely disagree with everything they say, but you hugely respect their opinion. And that can sometimes not be very obvious. Okay. Well, thank you so much for your time today, Niall. We wish you the best of luck with the rest of the Boost Outcome review process.

Thank you very much. And thanks, you guys, for bringing me on for this. It's very kind of you, and I hope that outcome solves a few needs for some people. It certainly solved a huge amount of need for my own code, and I hope that it will solve needs for other people. And that's the whole point of open source in the end. Right. Okay, thank you very much.

Thank you. Thanks very much. 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.