It's certainly not grounds for a rejection, unless you don't care about the Boost admission requirements.
"Don't care" is emotionally charged language. And also false. I care very much, especially for cases where the Boost admission requirements and review process show a weakness.
And yet here you are posting a review mostly made up of emotional concerns, not technical ones, not engineering ones. And not even factual ones - my first open source landed on the internet over 25 years ago, some of which is still actively supported by me. Nobody can claim that I haven't been at this for a very long time now, and have more than demonstrated my long term commitment.
I disagree. As we have seen in the recent survey, C++11 is overwhelmingly popular. Your advice to consider C++17 is exactly the type of bad decision-making that I am concerned about if Outcome is accepted into Boost. To wit, requiring C++17 would exclude 88% of potential Boost users. Even requiring C++14 excludes two-thirds of all C++ programmers. See:
This is such not an issue. At best, Outcome might land in the Summer release, more likely the Winter release. That means it doesn't reach end users until 2019, most of whom only update to a recent Boost every two years or so. So now we're talking 2021, a time by which C++ 11 users will be a minority.
...But the price is the compiler requirements, which are now high, because compilers just weren't reliably up to it until recently.
Part of the skill of a Boost C++ engineer is to figure out how to make it work on older compilers, without being too taxing on them. We suffer so the users don't have to.
Or, in fact the skill of a Boost C++ engineer is to see through fashionable concerns for what are actual, rather than commonly believed, engineering exigencies and design a truly correct library rather than one which ticks all the popular boxes and rouses the rabble. Anyone wanting to stick to C++ 11 for the next five years is unlikely to be a risk taker, and thus unlikely to want something like Outcome anyway. There is also a raft of end users who will be jumping straight from C++ 03 to C++ 17 because they like to track whatever is the last point bugfix before a major release (I know I do exactly this myself in everything from new computers to new cars, it saves such a huge amount of hassle, and you usually get great end of line discounts. But I digress). You've got some axe to grind on C++ 11 being far more important for potential users of Outcome than is actually the case. I don't know why. Even if it were a problem in 2018 for some kinds of end users who want Outcome, it definitely is much less of a problem in 2019. I've already had big corporates reaching out saying they are thinking of folding Outcome in with their toolchain upgrades in 2019, so the timing for them is perfect. Fundamental libraries like Outcome are always treated very conservatively because of the severe lock in and the fact your entire codebase will be ruined if the fundamental library ends up having a broken design or its ABI changes, breaking all your prebuilt DLLs. None of these issues are anything like as pressing with niche libraries such as Beast. So perhaps you don't get the conservatism at work here. Few big users will be adopting Outcome quickly, they'll take at least a year, maybe two. We're talking 2019, 2020 for most big users.
But maybe I can do something for you anyway. After failing to persuade
I think it too small a library to go into Boost alone, so I may just implement it into Outcome as an optional, and usable standalone to C++ 11, extension.
This is again the questionable decision-making that I am concerned about if Outcome is accepted into Boost. I consider adding a substitute for error_code to be outside the scope of the library. Such an addition should be in its own library and get its own review. You are effectively stating that you do not believe your idea has enough merit to survive a review, so you will simply add it to your already-published library.
I love how you read in whatever emotional interpretation you wish to twist in irrespective of facts. Firstly, said micro-library - and it's two classes, so it's a micro-library - is purely an experimental and optional extension. It won't be used by default, which will remain std::error_code. Secondly said micro-library is hardly being invented out of nothing. It addresses the consensus issues raised in https://wg21.link/P0824. Thirdly, who said it would not be reviewed here? You did, without evidence. It'll definitely pass before here for feedback before I start work on a proper implementation. Firstly I need to merge the substantial feedback from SG14, and get sign off from there.
I own almost all the copyright. I can license my work under any licence I like, including multiple licences under the Geneva Copyright Convention which is an international law. This is a non issue.
The problem comes when someone else wants to make a contribution. Do they have to agree to both licenses? Or just the one? If someone contributes to the BSL licensed portion in Boost, how will you bring it over to the "real" Outcome?
It almost sounds like you have no experience of managing open source libraries, yet you do. Multi licence codebases abound in software, and in open source. Most contributors are happy for their work to be licensed under whatever. Even I, a long time staunch opponent of the GPL, suck it down when sending in a patchset to a GPL codebase. If a contributor were not happy with the Apache 2.0 licence, then I'd rewrite their patchset. This almost never happens in practice. Apache 2.0 licence is highly uncontroversial.
is by far the incompatibility with C++11 (currently in use by two-thirds of all programmers). Some libraries can get away with requiring higher versions of the language, but this isn't one of them. An error variant is sorely needed by ALL C++ programmers not just the one-third with the luxury of C++14 or higher.
However, Outcome is not an error variant. The first Boost peer review clearly landed on a design which is not Expected. Perhaps that's the problem here in truth. You want a C++ 11 Expected. This library is not that. Hence you recommend rejection of this library, irrespective of usefulness, irrespective of engineering, irrespective of any other factor because you're not getting what you want, and I'm not doing what you want. What you should be saying is this: "This library does not suit my needs or the needs of many others. So I'm going to submit for review a library which does." I'd be more than happy to see someone write a high quality Expected implementation and submit it to Boost. It would complement Outcome nicely. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/