On Fri, May 19, 2017 at 7:13 AM, Niall Douglas via Boost wrote:

Outcome makes use of variable templates. There is still a code path using types instead, but it is used exclusively on MSVC and I aim to remove it as soon as Microsoft fix their compiler (I was told it'll be VS2017 Update 1).

So Outcome requires C++14 then? Does this mean that compilation with gcc 4.9.x is not supported?

I intend to drop support for VS2015 before Outcome enters Boost,

Although I have not yet attempted my own implementation of expected/outcome, it seems to me that an implementation using only C++11, or even only pre-C++11, is quite possible. There are still many shops that are "stuck" on particular older versions of Visual Studio. Restricting a generally useful library which parallels a standard library proposal, to only the latest version of Visual Studio sounds quite harsh. Thanks

On Fri, May 19, 2017 at 9:00 AM, Niall Douglas via Boost wrote:

The minimum known working compilers are listed at https://ned14.github.io/boost.outcome/prerequisites.html. As it says, you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed the bugs Outcome triggers in GCC 6). ... A proposed Boost library need only conform to the latest C++ standard. And as I hint at above, older compilers ICE a lot with Outcome. Use is much more stable on the most recent POSIX compilers. No point therefore in special casing Visual Studio, basically you need a compiler made last year or newer.

This means that out of the box, Beast cannot use Outcome, as Beast requires only C++11. When I contemplate what an implementation of expected/outcome might look like, I do not imagine anything that requires more than C++11. Possibly even less than C++11. When I look at the implementation of Boost.Outcome it seems needlessly over-engineered. I cannot help but think that the Internal Compiler Errors which result from attempting to build with earlier versions of C++ are a consequence of this over-engineering and could have been avoided with a more straightforward implementation. While it is true the letter of the wording regarding Boost library requirements do not mandate support for earlier compilers, I believe it is in bad taste to use such wording to provide cover for unnecessarily complex code. I feel that Outcome is sufficiently narrow in scope and broad in utility that it should not be limited only to "a compiler made last year or newer."

On Fri, May 19, 2017 at 10:35 AM, Robert Ramey via Boost wrote:

...

I feel that Outcome is sufficiently narrow in scope maybe you mean wide rather than narrow

Yes, that's what I meant - thanks!

This means that out of the box, Beast cannot use Outcome, as Beast requires only C++11. When I contemplate what an implementation of expected/outcome might look like, I do not imagine anything that requires more than C++11. Possibly even less than C++11.

When I look at the implementation of Boost.Outcome it seems needlessly over-engineered. I cannot help but think that the Internal Compiler Errors which result from attempting to build with earlier versions of C++ are a consequence of this over-engineering and could have been avoided with a more straightforward implementation.

You are very wrong on this. There are toy Expected implementations like the many you'll find around the web. Then there are STL quality implementations. They are *significantly* more complex because of all the niche corner cases which must be handled. For example, Expected must work correctly both in constexpr and non-constexpr, and any mix thereof. It must correctly propagate noexcept to its member functions based on the T and E it is configured with. It must inspect, with minimum compile time impact, T and E for what constructors and operators it provides, and what the noexcept and constexpr is on those, and again configure itself correctly as per the LEWG proposal. It must correctly handle throwing copy and move constructors and assignment, ensure that if T and E are trivially destructible then so is the Expected, and all whilst ensuring that nothing causes the optimiser to give up too early. It is that stuff which ICEs older compilers. In particular, MSVC likes to ICE on calculated noexcept. Older GCC likes to ICE on complex variable template expressions. Older clang also has issues with using variable template calculated values in default template parameters. The list goes on. You are probably right that a C++ 11 edition could be made. But it would likely be a completely new codebase and without the two years of maturation this code base has received. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

The minimum known working compilers are listed at https://ned14.github.io/boost.outcome/prerequisites.html. As it says, you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed the bugs Outcome triggers in GCC 6).

Hi Niall - This is a bit confusing. It sounds like gcc 6 or greater is needed. I can't think of a situation where ICE'ng the compiler is considered working.

It depends on how you use Outcome in your code. The compiler versions listed at https://ned14.github.io/boost.outcome/prerequisites.html are where Outcome passes all its unit tests clean. You can definitely write a lot of code using Outcome which doesn't ICE the compiler. However I also know from AFIO v2, which makes very extensive use of Outcome, that it blows up older compilers in all sorts of fun ways. If I took the time, I could rewrite how AFIO uses Outcome to not ICE the older compilers. But given how alpha AFIO v2 is, it's just easier to bump the compiler version needed for that library to a non-broken compiler version. That's my observation. I am not sure how to exactly document this informal experience in Outcome's docs. After all, it's the compiler vendors' fault, not Outcome's. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

If Outcome requires C++14 (or maybe C++17?) what is the value of including within Outcome a library which allows you to use C++11 standard library instead of boost? In other words, Outcome could already be written against the C++ standard library facilities, since they are guaranteed to be there in all versions of C++ which Outcome supports.

boost-lite is no longer part of this review at all now that tribool support has been dropped, but as you ask, boost-lite requires only C++ 11 because lots of libraries beyond Outcome use it, including some C++ 11 ones.

I also see things in boost-lite like array, thread, condition_variable, are those part of the public interfaces being proposed?

Apart from boost_lite::tribool which has now been dropped due to review feedback, nothing from boost-lite appears in the public interface. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 19/05/2017 20:15, Vinnie Falco via Boost wrote:

On Fri, May 19, 2017 at 12:12 PM, Niall Douglas via Boost wrote:

...

Apart from boost_lite::tribool which has now been dropped due to review feedback, nothing from boost-lite appears in the public interface.

Is BOOST_OUTCOME_USE_BOOST_ERROR_CODE part of the public interface? I see lines like this: https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1....

If reviewers make acceptance conditional on Outcome using Boost instead of the C++ 11 STL for everything, then that configuration would be activated and made permanent some how. Note it hasn't been tested in well over a year, but it used to work once and it could be resurrected without huge effort.

What does Outcome have to do with Boost.Thread? https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1....

It's stale. I didn't want to invest the effort of removing it until the review decides what form they want to accept Outcome in, if at all. You may have noticed the large matrix of #if statements building an ABI string, all that stuff takes lots of tedious effort to rejig. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 19 May 2017 at 22:03, Vinnie Falco via Boost wrote:

Niall: ... what is the value of including within Outcome a library which allows you to use C++11 standard library instead of boost?

C++11 should be banned (please, stop moving). degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

Niall Douglas wrote:

...

In the event the library is accepted, what will the contents of the repository boostorg/outcome be, and what will end up in the Boost release under libs/outcome?

That depends on what conditions the review manager places on acceptance, if acceptance is recommended.

Yes of course. My question was what you intend to happen.

As I've mentioned before, during build we assemble a single file include of all the dependencies, including those parts of boost-lite needed. There is therefore no strict need to ship boost-lite in any boostorg repo, which is good as I believe boostorg currently doesn't support project level subrepos.

This would only work if I use boost/outcome/outcome_v1.0.hpp, right? The headers in v1.0/ do not compile without boost-lite.

To be honest, I don't think it hugely important how we get Outcome into boostorg,

An interesting position. I, however, in order to decide between Yes and No, need to know what, precisely, will happen on Yes. Of course I could say Yes if you do such and so, otherwise No, but it's good to know how you see things and what's your intent.

...

As I already asked, will boostorg/outcome be the primary source repository for Boost.Outcome? If there is a PR submitted against boostorg/outcome, what steps will need to be performed in order for that PR to become integrated into the Outcome code base?

I'd prefer not a script generated boostorg/outcome repo, it makes maintenance harder.

I'm not sure I understand. If you prefer not a script-generated boostorg/outcome repo, what do you prefer?

Niall Douglas wrote:

...

I'm not sure I understand. If you prefer not a script-generated boostorg/outcome repo, what do you prefer?

There's script generated within my build system. That's okay, it's already doing that, indeed that's going to get much worse with issue #25.

Then there's script generated whereby a new git repo is one-way synthesised by cron script from another git repo (like ASIO). I'd prefer not to have to do this.

I still don't understand. Let me describe what I would like to see, and you'll tell me if you see things the same way. What I'd prefer to see is, in boostorg/outcome:include/boost/outcome, in addition to the outcome_v1.0.hpp header as currently generated, an outcome.hpp file that includes the headers in v1.0, as it currently does when BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE is defined. I also would like this to work without boost-lite, pcpp, gsl-lite being present at all in the boostorg/outcome repo (or on the user's system). Furthermore, when someone issues a pull request against boostorg/outcome:include/boost/outcome/v1.0/something.hpp, I'd like to see this pull request kicking off a travis build as we're now used to, with this travis build actually testing Outcome with the pull request applied. Does this make sense?

Niall Douglas wrote:

And finally, I do intend to keep Outcome working completely independent of Boost. The vast majority of my user base explicitly do not want a Boost dependency.

The vast majority of your user base may change if your library is accepted. It almost certainly will. Not wanting to depend on Boost is understandable. Our common infrastructure however is not just a whim of ours, it's a service to Boost users. Going through BOOST_ASSERT and BOOST_THROW_EXCEPTION instead of rolling your own is more convenient for people who have already configured BOOST_ASSERT and BOOST_THROW_EXCEPTION to do what they want them to do and would rather not repeat that exercise for every new library, however wonderful. Similarly, once we get the kinks out of Boost.Stacktrace, it might be better to use that instead of #including . All that's not strictly required for acceptance, in principle; neither is using Boost.Config instead of rolling your own. And yet. Regarding the ring buffer, I agree that it adds value. But it also adds complexity. There's an argument to be made for result/outcome classes that simply store std::error_code without all the bells and whistles, and provide an optional hook to which the user can attach the ring buffer if needed. You already have a macro-based hook for that, although I'm thinking more of a callback. Finally, you don't even need to macro-bind to std::error_code. Inspired by Outcome, I wrote a pull request for Boost.System which makes the Boost error_category, error_code and error_condition convertible to the standard ones, so you can just store std::error_code and be done with it. https://github.com/boostorg/system/pull/16

...

And finally, I do intend to keep Outcome working completely independent of Boost. The vast majority of my user base explicitly do not want a Boost dependency.

The vast majority of your user base may change if your library is accepted. It almost certainly will.

I would still expect a vast majority to not want a Boost dependency. People want C++ 14 libraries to use the C++ 14 STL, not Boost, though *optional* non-default usage of Boost stuff appears to be popular.

Not wanting to depend on Boost is understandable. Our common infrastructure however is not just a whim of ours, it's a service to Boost users. Going through BOOST_ASSERT and BOOST_THROW_EXCEPTION instead of rolling your own is more convenient for people who have already configured BOOST_ASSERT and BOOST_THROW_EXCEPTION to do what they want them to do and would rather not repeat that exercise for every new library, however wonderful.

Outcome only ever throws an exception via a macro. It can be customised. If reviewers wish it, we can have the default use BOOST_THROW_EXCEPTION.

Similarly, once we get the kinks out of Boost.Stacktrace, it might be better to use that instead of #including .

Including Outcome does not include , except on winclang because winclang won't compile my win32 namespace anti-collision hack which MSVC will. The stack trace optionally collected by error_code_extended is completely standard and can be fed to Boost.Stacktrace, or to any other stack trace library. The default printer provided by Outcome is rudimentary, but sufficient. I personally feed the addresses printed to addr2line by hand when I need to, it works. I would be very open to using Boost.Stacktrace instead if detected with #if _has_include

All that's not strictly required for acceptance, in principle; neither is using Boost.Config instead of rolling your own. And yet.

Boost-lite macros can be swapped for Boost.Config ones if reviewers wish it. I should mention that boost-lite derives its macros from the C++ 17 feature macros, which all recent editions of major compilers support even in C++ 14 mode. In other words, it is not compiler version based, except on old compilers, but it does rely on compiler vendors telling the truth (they generally do).

Regarding the ring buffer, I agree that it adds value. But it also adds complexity. There's an argument to be made for result/outcome classes that simply store std::error_code without all the bells and whistles, and provide an optional hook to which the user can attach the ring buffer if needed.

The tutorial covers the need in real world code to attach some sort of payload to error codes. Outcome provides error_code_extended with a reasonable set of the most common likely payloads. If reviewers would prefer a vanilla error_code to be the default, that's very easy to fix. I would add that if you do not use any of the payload, error_code_extended is identical to an error_code, no overhead.

Finally, you don't even need to macro-bind to std::error_code. Inspired by Outcome, I wrote a pull request for Boost.System which makes the Boost error_category, error_code and error_condition convertible to the standard ones, so you can just store std::error_code and be done with it.

https://github.com/boostorg/system/pull/16

I'll leave it to reviewers to decide on whether defaulting to the C++ 14 STL std::error_code or to boost::error_code is the most appropriate. It's very easy to change. And as I've mentioned before, if reviewers really want a completely boostified edition of Outcome, that's no problem, I can make that work. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 21/05/2017 14:39, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

...

The vast majority of your user base may change if your library is > accepted. It almost certainly will.

I would still expect a vast majority to not want a Boost dependency.

The vast majority get their Boost libraries through some form of a Boost release.

The vast majority do something like: apt-get install libboost-filesystem-dev So they ask for the library they need, and get lots of other stuff too (filesystem is actually pretty good, only four or five dependent boost libraries, others basically drag in libboost-all-dev)

For them, the phrase "a Boost dependency" makes no sense at all. You could legitimately talk about depending (or not depending, which is preferable) on a specific Boost module, but not depending on Boost in general has no meaning when you're part of Boost in general.

All the evidence to date suggests that people far prefer Boost libraries without the monolithic Boost dependency, and especially without a Boost.Build dependency. Standalone ASIO is much more popular than Boost.ASIO Standalone Hana I am told is much more popular than Boost.Hana, but maybe Louis will confirm or deny. I expect the same to be the case with standalone Outcome. An overwhelming majority of developers outside boost-dev want Boost quality libraries without the Boost dependency. This topic comes up **very** frequently on Reddit and Stackoverflow. People have tried to explain this here on boost-dev, but it has not been well received. I don't want to rehash those arguments during this review. I've said all I intend to on that topic. I will reiterate that if reviewers want a boost-flavoured Outcome which doesn't default to the C++ 14 STL, that's no problem to achieve.

...

People want C++ 14 libraries to use the C++ 14 STL, not Boost,

Not a problem at all here, but not what we're talking about. You've eliminated a dependency on Boost, but substituted a dependency on something called Boost Lite. For people who acquire your library as part of Boost, this is not an asset, it's a liability. (For those who don't, it's vice versa.)

It is not a dependency if it comes bundled internally. Which it does. No external downloads nor installs needed unless you are using the git repo (and even then, fetchRecurseSubmodules is set to true, so a simple git submodule update should work if your git is new enough).

...

I should mention that boost-lite derives its macros from the C++ 17 feature macros, which all recent editions of major compilers support even in C++ 14 mode.

Does MSVC support SD-6 macros? I thought that it didn't.

I believe they appeared in an update of VS2015, and are present in VS2017. __has_include also appeared and mostly works, though it is buggy.

...

The tutorial covers the need in real world code to attach some sort of payload to error codes. Outcome provides error_code_extended with a reasonable set of the most common likely payloads.

Yes, the need to attach more information to error codes is genuine. For exceptions Boost.Exception lets us do that non-intrusively, but for error codes we do not have a similar framework.

Boost.Exception allocates memory to do that. Allocation of memory is not possible anywhere in Outcome, it ruins the point of using it for low latency C++ which is a big user base.

Speaking of which, can you please give me a few examples of what goes into the two codes (code1 and code2)?

Totally up to the end user. You could store a void * across both 32 bit codes. You could store a thread id in one and the bottom 32 bits of this in the other. Lots of options. I chose 64 bits as it's the minimum which is versatile. In my own code, I define a local make_errored_result<>() function which wraps the Outcome one, but adds in custom code1 and code2 where appropriate.

...

I would add that if you do not use any of the payload, error_code_extended is identical to an error_code, no overhead.

Apart from the additional size_t.

I benchmarked the effects of that additional 8 bytes. No statistically measurable difference.

But it occurs to me that you can hide that on x64 if (a) you make it 32 bit - should be enough for a ring buffer - and (b) you do not derive from std::error_code but instead store the members directly in the correct order.

int32_t cookie_; int value_; std::error_category const * cat_;

The ability to implicit type slice an error_code_extended to an error_code may well be felt to be an issue by reviewers. If explicit conversion were felt desirable despite creating boilerplate, then definitely yes you'd optimise storage. But as I mentioned, I found no statistical difference in performance with the additional 8 bytes. After all, one is not creating large arrays of error_code_extended.

...

I'll leave it to reviewers to decide on whether defaulting to the C++ 14 STL std::error_code or to boost::error_code is the most appropriate.

I'm not sure you understand me here... I'm saying that there's no need to default to boost::error_code or even keep the stl11:: way of choosing between the two.

Retaining standalone usability of Outcome is a high priority for me. A lot of folk from SG14 are interested in using Outcome, and I intend to submit Outcome into SG14's collection of low latency suitable libraries. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

Totally up to the end user.

I know that it's totally up to the end user. I'm asking for a few real-world examples of use. What do you use them for, what do your users use them for?

Oh, ok. Here's an example from https://github.com/ned14/boost.kerneltest/blob/5bf4b78569366198af745ec6b7319...: // If this is empty, workspaces are identical resultstl1z::filesystem::path workspaces_not_identical = compare_directories(current_test_kernel.working_directory, model_workspace); // Propagate any error if(workspaces_not_identical.has_error()) testret = error_code_extended(make_error_code(kerneltest_errc::filesystem_comparison_internal_failure), workspaces_not_identical.get_error().message().c_str(), workspaces_not_identical.get_error().value()); // Set error with extended message of the path which differs else if(workspaces_not_identical.has_value()) testret = error_code_extended(make_error_code(kerneltest_errc::filesystem_comparison_failed), workspaces_not_identical.get().string().c_str()); So compare_directories() walks two directory structures using the Filesystem TS and compares them for equivalence using fuzzy criteria. Here we use the empty state to indicate "directory trees are identical", an error state to indicate an error occurred, and a valued state to give the path of the first item which differed. (I know this looks like an inverted logic from traditional outcome usage, but this shows exactly the usefulness of the three-state outcome. Here empty is "failure to find a difference", valued is "succeeded to find a difference") If there was an error, we return an error code of kerneltest_errc::filesystem_comparison_internal_failure with a payload of the string message from the source error and its original error code in the first 32 bit code1 integer. That is used later on to print the exact error code returned by the system as we know it will always be system_category. If the directory structures differed, we return an error code of kerneltest_errc::filesystem_comparison_failed with a payload of the string of the path which did not match. Is this sufficient, or would you prefer a different example?

...

...

...

I'll leave it to reviewers to decide on whether defaulting to the C++ >> 14 STL std::error_code or to boost::error_code is the most appropriate.

I'm not sure you understand me here... I'm saying that there's no need > to default to boost::error_code or even keep the stl11:: way of choosing > between the two.

Retaining standalone usability of Outcome is a high priority for me. A lot of folk from SG14 are interested in using Outcome, and I intend to submit Outcome into SG14's collection of low latency suitable libraries.

I'm now sure that you don't understand, because your answer makes no sense. I'm telling you TO NOT USE BOOST::ERROR_CODE, and you tell me that you'd rather retain standalone usability. Hello?

Unless I have misunderstood your patch, you bring in error_condition comparisons from allowing one to compare error codes to error conditions across both Boost and STL error categories. This is fine, and indeed valuable. But it isn't relevant to Outcome particularly because we cannot say what the end user is doing with their error_code, and certainly not if whatever they are doing has any relation to error_condition. For example, as mentioned earlier in the thread, Chris was using a custom http_error category for the HTTP status codes. That has no useful mapping onto error_condition except for the identity map, and most code will therefore just go ahead and use the error code directly and save on the boilerplate. One could create one's own error_code implementation which uses the STL or Boost error categories, and provide mapping into error_condition. This would let you embed whatever payload you like into Outcome's error_code. Indeed, if reviewers dislike error_code_extended storing the payload into global static memory like it does, the next least worst solution is probably one's own custom error_code implementation with user definable payload. But this is not a cost free design choice, you lose compatibility with all code using std::error_code. The current design lets you do stuff like static_cast from a passed in error_code& to an error_code_extended& if you know the original is definitely an extended error code. I figured that much more likely a use case in say something like ASIO which is hard wired to use const error_code&. But maybe it's a price worth paying. Let's see what reviews recommend. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

Is this sufficient, or would you prefer a different example?

Thanks, that's very helpful.

The use case here is similar to std::throw_with_nested, you have an error_code that you are overriding with another. You could extend your ring buffer facility to support this natively. For that, you need to store in the buffer entry the error code (a duplicate of error_code_extended's members) _and_ the unique_id of the "parent" error_info_extended. This would allow you to later retrieve the whole chain of ring buffer entries (subject to availability.) In your example, you'd do

testret = error_code_extended( kerneltest_errc::filesystem_comparison_internal_failure, workspaces_not_identical.error() );

Since workspaces_not_identical.error() is already in the ring buffer, you only need a 'pointer' to it in testret. There's also no need to pass its message() in testret's message, you could use that for other purposes.

Actually it's not in the ring buffer, it was an error code raised by the Filesystem TS implementation. No extended info because it had nothing to do with Outcome. There is no way to chain extended info's because the ring buffer keeps the extended information only. If you wanted to implement a chain, as the Outcome FAQ mentions you can convert your error_code_extended into an exception object and chain them via the STL's nested exception framework. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Niall Douglas wrote:

Unless I have misunderstood your patch, you bring in error_condition comparisons from allowing one to compare error codes to error conditions across both Boost and STL error categories.

This is fine, and indeed valuable. But it isn't relevant to Outcome particularly because we cannot say what the end user is doing with their error_code, and certainly not if whatever they are doing has any relation to error_condition.

What the patch does is make boost::system::error_code and boost::system::error_condition convertible to std::error_code and std::error_condition. The idea is that a function that returns std::error_code can use a function that returns boost::system::error_code in its implementation and can then return it directly. In cases where the original boost::error_code can be compared to boost::errc::foo, the converted std::error_code can be compared to the equivalent std::errc::foo. In addition, if the original boost::error_code can be compared to a custom boost::error_condition, the converted one can be compared to the converted std::error_condition. Long story short, the relevance to Outcome is that you can always store std::error_code in result/outcome, even if the user passes you a boost::error_code (because it will convert). There is no need to choose at compile time which of the two to store, because you can take both. That is, the function result<T> make_error_result( std::error_code const & ec ); will now be able to take Boost error codes as well.

Long story short, the relevance to Outcome is that you can always store std::error_code in result/outcome, even if the user passes you a boost::error_code (because it will convert). There is no need to choose at compile time which of the two to store, because you can take both. That is, the function

result<T> make_error_result( std::error_code const & ec );

will now be able to take Boost error codes as well.

Ah now I get it. Your patch adding that support is a great bit of work then. Thank you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

The way I see it, if you want to be part of Boost, you should be a "good" member of Boost, and this does mean to *by default* include config, assert with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other things. You can then support others users, for example let them #define OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.

Outcome is a good member of Boost. It ticks every box on the list of requirements at http://www.boost.org/development/requirements.html except for Boost.Build support. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Sun, May 21, 2017 at 2:35 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

The way I see it, if you want to be part of Boost, you should be a "good" member of Boost, and this does mean to *by default* include config, assert with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other things. You can then support others users, for example let them #define OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.

Outcome is a good member of Boost. It ticks every box on the list of requirements at http://www.boost.org/development/requirements.html except for Boost.Build support.

I did not mean to suggest that this is a requirement, I said "should" not "must". For example, if you don't use BOOST_THROW_EXCEPTION to throw, users won't have the file, line and function name of the throw when calling current_exception_diagnostic_information; and if you don't at least use boost::throw_exception, you create problems for users who use Boost under BOOST_NO_EXCEPTIONS, which seems would include users of Outcome.

...

Standalone ASIO is much more popular than Boost.ASIO

What do you base this statement on?

Back when I did the research for my C++ Now talk on the future of Boost, I did a search of open source projects #including "asio/asio" as against "boost/asio". The "asio/asio" ones outnumbered "boost/asio" by approx 50% if I remember rightly. I am subscribed to asio questions on stackoverflow, and there is a noticeable pattern that people with beginner level questions use boost.asio, whereas the tricky questions they are using standalone asio. That suggests the serious users of ASIO use the standalone edition. Finally, a quick google search of "boost.asio vs standalone asio" reveals most of the top results recommend using standalone asio if you have C++ 11 or better. The most common reason given is "because it is truly header only and it doesn't drag in Boost". Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2017-05-23 1:56 GMT+02:00 Jared Wyles via Boost :

Hello,

One of the questions that is inevitably asked when a proposal to switch to using something like outcome is that of exceptions. Why outcome over exceptions etc which you briefly touch on in your ACUU talk. With that in mind, when attempting to sell this library having the motivating example on the boost.outcome docs using exceptions really makes starting the discussion harder. I understand one can never escape exceptions, but it shouldn't be used as the first example a new user sees. I would like to see this example updated to show how to handle errors with out the need for exception handling around accessing *value*. Personally, I see something similar to https://ned14.github.io/boost.outcome/md_doc_md_03-tutorial_ b.html#expected_payload as a much better example to help sell outcome and therefore better suited as the motivating example for the front page of the docs.

This means, the initial example should use `boost::outcome::result` (instead of `boost::outcome::outcome`). And then function that inspects the result could read: ``` void test() { if (auto r = fun) use_int_value(r.value()); else inspect_error_code(r.error()); } ``` Regards, &rzej;

Le 23/05/2017 à 12:35, Andrzej Krzemienski via Boost a écrit :

2017-05-23 8:50 GMT+02:00 Andrzej Krzemienski :

...

2017-05-23 1:56 GMT+02:00 Jared Wyles via Boost :

...

Hello,

One of the questions that is inevitably asked when a proposal to switch to using something like outcome is that of exceptions. Why outcome over exceptions etc which you briefly touch on in your ACUU talk. With that in mind, when attempting to sell this library having the motivating example on the boost.outcome docs using exceptions really makes starting the discussion harder. I understand one can never escape exceptions, but it shouldn't be used as the first example a new user sees. I would like to see this example updated to show how to handle errors with out the need for exception handling around accessing *value*. Personally, I see something similar to https://ned14.github.io/boost.outcome/md_doc_md_03-tutorial_ b.html#expected_payload as a much better example to help sell outcome and therefore better suited as the motivating example for the front page of the docs.

This means, the initial example should use `boost::outcome::result` (instead of `boost::outcome::outcome`). And then function that inspects the result could read:

``` void test() { if (auto r = fun) use_int_value(r.value()); else inspect_error_code(r.error()); } ```

The initial example could look like this: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro.md

THis is a better example of what Outcome can do, yes. Would the following works as well? I have changed just outcome by expected. What if fun returns an expection ptr? auto my_fun()noexcept -> outcome::expected<int> { std::error_code ec; int i =Library1::fun(ec); if (ec) return outcome::make_errored_outcome(ec);// error code returned inside outcome BOOST_OUTCOME_TRY(rslt2,Library2::fun());// if fun() succeeds, rslt2 of type int contains result // otherwise returns the result of fun() up BOOST_OUTCOME_TRY(rslt3,Library3::fun());// Similarly, either rslt3 is an int with successful result, // or my_fun() returns what Library3::fun() has returned return i + rslt3;// return a result with a value }; Best, Vicente

2017-05-24 17:00 GMT+02:00 Niall Douglas via Boost :

...

...

...

This means, the initial example should use `boost::outcome::result` (instead of `boost::outcome::outcome`). And then function that inspects the result could read:

``` void test() { if (auto r = fun) use_int_value(r.value()); else inspect_error_code(r.error()); } ```

The initial example could look like this: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro.md

THis is a better example of what Outcome can do, yes.

You both would prefer that the landing page motivating example not show how outcomes can also transport caught C++ exceptions through non-C++ exception code?

Actually, what I am suggesting goes beyond the initial example. My suggestion is driven by the advice form Robert Ramey: that the potential users are impatient: you have like 1 minute to attract their attention, and like 5-10 minutes to go through the features without loosing their interest. So, I would do something like we have in the documentation for Boost.Optional. The initial page is very short. Short description and a really small example. In fact too small to sell the power of this library: http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/index.html And then in a number of subsequent pages, we describe feature by feature with short examples: http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/q... http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/q... http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/q... http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/q... http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/q... I would do the same for Outcome: In the landing page just give this example: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro2.md It only introduces `outcome::expected` (lot of users will not have heard of `std::expected`) and the TRY operation to attract attention of more informed users. Then in the second page I would provide a number of short capters each with one annotated example, each introducing one feature: - one for using payload wit error_code - one for all TRY operations - one for interaction with exception_ptr - one for catching exceptions into `outcome` - one for different ways of accessing the state of `outcome` If you like this idea, I would volunteer to write up the initial pages. Regards, &rzej;

One of the questions that is inevitably asked when a proposal to switch to using something like outcome is that of exceptions. Why outcome over exceptions etc which you briefly touch on in your ACUU talk. With that in mind, when attempting to sell this library having the motivating example on the boost.outcome docs using exceptions really makes starting the discussion harder. I understand one can never escape exceptions, but it shouldn't be used as the first example a new user sees. I would like to see this example updated to show how to handle errors with out the need for exception handling around accessing *value*. Personally, I see something similar to https://ned14.github.io/boost.outcome/md_doc_md_03-tutorial_b.html#expected_... as a much better example to help sell outcome and therefore better suited as the motivating example for the front page of the docs.

The motivating example on the landing page is very tricky to get right. It can't be too long, else people give up instantly. It can't use too much library specific stuff, else it overwhelms. It has to assume a very wide range of viewer knowledge and capability. Yet it must still communicate the library in an instant, including that it works well with mixed C++ exceptions enabled and disabled codebases. The current motivating example was written by Andrzej because my previous one wasn't representative enough. I am not a good person to write these landing page code examples, I never look at them when looking at a library and they play zero part in my evaluation of a library when considering to use it. So I have no idea what other people, who do rely on these heavily, look for. Vicente suggested a different example by Andrzej instead. I will re-ponder that one. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

- What is your evaluation of the documentation?

Hard going. Niall knows far, far, far too much already? Get someone else to write a tutorial on 'how to use outcome'?

This saddens me. Can you suggest particular hard going parts?

(I expected a folder in /libs called outcome, but I got one called boost.outcome so it wasn't in the alphabetical order or format that I expected, but I found it :-)

You need to do "git clone https://github.com/ned14/boost.outcome.git outcome" if you want to rename the output directory.

I expected to be able to run the examples using b2 but sadly this is not supported. Is there any reason why not (apart from an aversion to bjam?) Boost has a system (even if not the best or Niall's preference) for running on multiple platforms and this doesn't fit with it which feels Boost-unfriendly at least.

Outcome provides a very rich cmake experience. If accepted, I will implement bjam support.

However, it appears to run OK from the IDE 'start without debugging' but produced no output. Not comforting. It really isn't my idea of a simple example. So I tried expected_payload1.cpp since it looks (and was recommended) as a better working example. (VS moans about deprecated Posix names, but hey... and boost.outcome\example\expected_payload2.cpp(27): warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', possible loss of data is ugly).

You hit on a good observation. More than half of the examples are not usable as programs, they are only there to compile successfully and get sucked into the documentation as code example. I've logged the issue to https://github.com/ned14/boost.outcome/issues/37.

The output "Failed to open file somefile due to 2" isn't an exemplary error message, even if it is only trying to show how outcome works. (Putting this string "Failed to open file somefile due to 2" as a comment would make it easy for the reader to understand without actually running the example).

Grr. Your STL's printer for error_code is not being helpful.

I tried to run the test expected_pass.cpp but got

modular-boost\libs\boost.outcome\test\expected_pass.cpp(15): fatal error C1083: Cannot open include file: '../boost-lite/include/boost/test/unit_test.hpp': No such file or directory

but it looks plausible. Again I'd expect a jamfile to do this.

If you don't want to use cmake, I placed a batch file in test called "withmsvc.bat" which speaks the right incantation for MSVC.

In the end, we now have to decide if this is all going to be 'OK in the end' and have faith in Niall's skill, judgement, and determination to see this functional and finished. I do. So that's a yes.

Many thanks for the review, and I am sorry that compiling and running code went so badly for you.

Nits noted ==========

Lots of files missing Boost licence. This is of course essential for Boost.

All of the implementation files, bar the auto generated one, should have licence boilerplate. The boilerplate is actually generated by a python script incidentally, saves me having to remember. You're right that the examples are missing those, historically due to doxygen. Logged to https://github.com/ned14/boost.outcome/issues/38 The test/expected_pass.cpp file is not my code, it's Vicente's from his test suite. If he prepends some licence boilerplate to his, it'll get picked up in mine.

Some punctuation and a nicer:

This eliminates the fragile switch statements converting between error code domains in favour of an information loss-free transmission. The cost is once again a loss of type safety because if a function might return an error code, it should never be able to return and the compiler will not complain.

Fixed in develop branch. Thank you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

(Maybe, it is even possible instead to provide some hints to compiler-vendors where to try to improve their optimizers?)

Back some years ago I submitted bug reports with repros to clang and MSVC regarding the low quality of optimisation with Outcome. I have no idea if the repros were used, but the most recent versions of both compilers do significantly better than previous versions.

...

- Do you think the library should be accepted as a Boost library?

Yes, I would say so. This would be an unconditional yes, even though I would suggest to add a small "introductory-tutorial" to the documentation and would like to hear what Niall (and others) think about my above remarks concerning removal of "option" and re-checking of the specific compiler-optimizations.

Option is just a typedef, very easy to remove. Andrzej I think just volunteered to redo the landing for me to match what you want. Thank you for your review! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

GitHub: https://github.com/ned14/boost.outcome

Question: Is the intention to include it in Boost under the Boost License only? I see files that have the Apache license in addition to the Boost license.

It is licensed under your choice of either the Apache 2.0 or Boost licences. As the licence.txt file says. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Fri, May 26, 2017 at 5:22 PM, Robert Ramey via Boost wrote:

The documentation is built with Doxygen - which, though convenient, works against producing helpful readable documentation.

I must object. Both Beast and NuDB use doxygen in their toolchain, and I think these pages are perfectly helpful and readable: http://vinniefalco.github.io/beast/beast/ref/websocket__stream/async_read.ht... http://vinniefalco.github.io/nudb/nudb/ref/basic_store/fetch.html If these pages look familiar, its because they use the same doxygen, xslt, and boost.book toolchain that Boost.Asio uses: http://www.boost.org/doc/libs/1_64_0/doc/html/boost_asio/reference/basic_str... So don't blame the tool, but blame the configuration. Doxygen generated HTML is terrible but with a decent XSLT program you can turn that worm into a butterfly. In fact, I have written such a library that can be included in anyone's C++ project to produce documentation that resembles that of Boost.Asio and Beast. Its called docca: https://github.com/vinniefalco/docca With some effort, Outcome could integrate docca and get documentation similar to the examples I provided above. I tried such an integration but I was stymied by the need to run a python preprocessor over the Outcome source code in order to produce valid C++ which Outcome requires, so I gave up. I am sure that the Outcome author could perform an integration since he is much more knowledgeable about his own code base - I am available to offer assistance with the docca portion. Thanks

On 5/26/17 11:57 PM, Vicente J. Botet Escriba via Boost wrote:

...

I believe what Robert mean is that the generated documentation of Boost.Outcome using doxygen has a lot of flaws. Of course it is tempting to say that it is because of doxygen.

As you showed in the examples we can do better. Using Doxygen requires to be more careful and sometimes replace some possible issues by workaroounds.

Nevertheless Doxygen on code using the pre-processor is a nightmare. Have you experience on these cases?

I will tale a deeper look at your examples :)

I understand the appeal of Doxygen. The idea if annotating the code with narrative comments which can accessed in a user friendly form is very appealing. It's natural for a programmer, easy to do, easier to keep up to date and is less tedious than building a giant reference after the fact. It also embodies the ideas and principles of literate programming in a practical way. So I see a lot of good in it. BUT a) It's support for templates is limited to specification of template parameters. It has no way to specify Type Requirements (aka concepts) aside from just typing in the narrative. It has no way to specify a concept and refer to it. b) It's doesn't seem a convenient method for specifing things like tutorials, examples, design concepts etc. c) By providing a place to add a little narative to each method it gives the programmer the impression that he's documenting his library - which he is not actually doing. In most cases all he is doing is making the comments in the code visible through some browser. Nothing wrong with this, but he's not really adding anything that one couldn't gain from just browsing the source code. d) If your source code isn't readable, you can create the impression that it's designed when it fact it isn't. That is it's useful for obscuring the fact that your code actually doesn't have any kind of design. So, for fans of Doxygen who have nothing else to do: a) Figure out how Doxygen customization works. I see this is huge slew of macros and settings which .... - well I don't know what it does. I guess it needs better documentation or perhaps design. b) Figure out how to express a concept in Doxygen and refer to it. c) Restrict usage of Doxygen to building xml reference pages for classes and class templates, functions and function templates. d) figure out how to meld this reference boost book using some other tool like quickbook, xml_mind, emacs or whatever. e) Be sure you make a good explanation so some naive person can create library documentation with your tools. e) If you get all this right - a tall order - be prepared to invest a lot of effort to evangelize your solution. This will be a very long and frustrating exercise. Or if you want to strike out on your own separate path - generally my own personal preference - you might consider an approach like caramel which would build on the idea of embedding boost book tags in comments and post processing the code. That's all I have to say about that. Robert Ramey

On 5/27/17 9:19 AM, Rene Rivera via Boost wrote:

On Sat, May 27, 2017 at 11:09 AM, Robert Ramey via Boost <

...

Or if you want to strike out on your own separate path - generally my own personal preference - you might consider an approach like caramel which would build on the idea of embedding boost book tags in comments and post processing the code.

You can also just include Quickbook docs in your source and include those in a coherent manner in your regular quickbook docs. Since there's no "automatic" class, function, etc. mechanics it forces you to write real documentation in your source where it's also accessible to people just browsing code. It also make it easier for people to contribute to your project as they submit docs along with code changes. This approach has been essential in getting a good number of external submissions to Predef, for example.

So that's even a fourth way. and there are probably more. I would like to emphasize that this is not an easy task. It's not just a question inserting a new, clever and cool little tool into the documentation tool chain. It's about changing the developer mindset about what documentation is and should be. The reason this is very, very difficult is that everyone thinks that they're not the problem - that other people are. But if that were true, there would be no complaints about documentation. It's also my view that difficulties in writing documentation reflect bad design decisions. But I'm having problems convincing developers of that. (I wanted to move this to a root thread but it's not showing that way on my news server output) Robert Ramey

On Sat, May 27, 2017 at 9:09 AM, Robert Ramey via Boost wrote:

I understand the appeal of Doxygen. ... BUT ... c) By providing a place to add a little narative to each method it gives the programmer the impression that he's documenting his library - which he is not actually doing. In most cases all he is doing is making the comments in the code visible through some browser. Nothing wrong with this, but he's not really adding anything that one couldn't gain from just browsing the source code.

Right. I'd like to make it clear to all readers of my posts which promote Doxygen and my docca library, that I am advocating for its usage specifically to build ONLY a "reference." That is, a synopsis of each public symbol (functions, classes, constants, etc...) exposed by the library, with appropriate helpful descriptions. Example: http://vinniefalco.github.io/beast/beast/ref/http__read_some/overload1.html Good documentation MUST include more than just this reference, it should also include the exposition that we have become accustomed to in Boost library documentation. An explanation of the audience, what problems the library solves, holistic tutorial on how to put things together to achieve a goal, and so forth. This of course will not be captured by Doxygen and instead should be developed as its own separate source code which is edited by hand much the way someone might write a novel. The approach used in docca and Beast is to incorporate this additional exposition not generated by doxygen as a set of ".qbk" files. The reference is then included as a pice of this larger work. To reiterate, Doxygen is a very useful piece (but not the only part) of a documentation tool chain in order to generate a reference from Javadoc comments attached to declarations in source code. It should be part of a larger work that includes the traditional exposition found in high quality documentation.

On 5/27/17 6:55 AM, Niall Douglas via Boost wrote:

I thus settled on doxygen as being the least worst of the alternatives ...

I do believe that a number of us - and like more users of boost - see a problem. That is that they agree with me. But it's not nearly as easy to address as one would first think. I don't want to denigrate Doxygen, it's a real sincere effort and not without value - but the whole literate programming thing needs more work. Robert Ramey

On 5/27/17 6:29 AM, Niall Douglas via Boost wrote:

On 27/05/2017 01:22, Robert Ramey via Boost wrote:

...

...

*- Error-handling algorithmic composition with-or-without C++ exceptions enabled

I would drop just about all the references to exceptions. It's an orthogonal issue. If you've decided you need exceptions or that they are convenient in your context, you're not going to change to outcome. If you've already decided on returning error indicators (for whatever reason), you're not going to switch to exceptions. You might want to switch to outcome. So comparison with exceptions isn't really relevant at all.

You may have a missed a major use case for outcome: calling STL code in a C++ project which is C++ exceptions disabled. These applications are not using exceptions right now. They might use outcome as an alternative to an integer return code. But exceptions are not relevant to this case.

Much of the games and

finance industry are interested in Outcome precisely because of the ease Outcome enables passing through C++ exceptions thrown in a STL using island through code with exceptions disabled.

I have to confess it never occurred to me what happens when a program compiled with exceptions disabled uses the "throw" statement. I would have assumed that it would fail to compile.

Even if you're not doing that, another major use case is to keep exception throws, and having to deal with control flow inverting unexpectedly, isolated into manageable islands. The rest of your intermediate code can then assume no exception throws, not ever. That means no precautionary try...catch, no need to employ smart pointers, no need to utilise RAII to ensure exception safety. It can be a big time saver, especially during testing for correctness because it eliminates a whole load of complexity.

I get this. But this is likely already being addressed with code like: // presume that sqrt throws when passed a negative number or Nan or??? float safe_sqrt(float x, int & error_flag){ float y; try { y = sqrt(x); error_flag = 0; } catch(const std::domain_error & de){ error_flag = 1; } return y; } which you would recommend replacing with something like: // presume that sqrt throws when passed a negative number or Nan or??? outcome safe_sqrt(float x){ float y; try { y = sqrt(x); return outcome(y); } catch(const std::domain_error & de){ return outcome(0); } } Which I would agree would be an improvement. BUT it really has nothing to do with exceptions per se. outcome is replacing exceptions, it's replacing an ad hoc integer error code/result combination with a better one. So I would personeally have limited references to exceptions to a small example similar to the above.

...

Pretty much the same for error codes. You might or might not use them - but this is a totally orthogonal question as to whether you use outcome or not as it is (I think) designed to handle any type as an error return type You are thinking of expected where E is selectable by the end user.

Outcome's outcome<T> and result<T> hard code the error type to error_code_extended. So error codes are the only game in town for those refinements. Hmmm - it didn't get that the E parameter had to be error_code. I

I wasn't thinking of Expected. I saw Vicent's presentation of it some years ago and found it unconvincing so I forgot about it. thought it could be anything - which would have decoupled outcome from error_code.

...

Eliminating all the irrelevant material would make the package much, much easier to evaluate and use.

With respect Robert, I don't think you understood all the use cases.

Right - that's my complaint. I read the documentation. I saw a 3 cases in the introduction. It wasn't apparent that it would be useful for things other than that.

Most have called for significantly *more* documentation to cover in detail even more use cases, not less.

Maybe - Either there other use cases that aren't in the docs or they're wrong. If they're other uses cases which aren't obvious, that's sort of red flag for me. It suggests that either the library might have non-obvious behavior. But I'm just commenting on what I currently see.

(Incidentally I tried less documentation three times previously. For some reason, people need to be hand held more when it comes to describing really simple and obvious-to-me at least stuff)

More is not necessarily better

...

...

*- No dependencies (not even on Boost)

Yowwww. This terrible. I looked a little through boost-lite. config.hpp - repeats a lot of stuff from boost/config. Doesn't seem to provide for compilers other than gcc, clang and some flavors of msvc.

It actually provides for all the C++ 14 compilers currently available. If they are not MSVC, GCC nor clang, they pretend to be one of those, so the same detection routines work.

You may also have missed the extensive use of C++ 17 feature test macros. All C++ 14 compilers, even MSVC, support those now.

Right - this is the wrong approach. If you think that boost/config.hpp needs fixing you can address that. But mixing configuration into a particular library just generates more work rather than factoring out into the best implementations.

...

Looks like some stuff might have some value - but with not docs/comments it's pretty much useless if something goes wrong - like a compiler upgrade.

The C++ 17 feature test macros ought to be observed by all future compiler upgrades.

...

chrono.hpp - what is this doing in here?

precompiling <tuple> etc..... Looks like you're trying to solve some other problem here -

goes on an on.

I think you didn't realise those are the namespace bind files allowing the C++ 11 STL to be switched with the Boost STL. They are auto generated by a clang AST parser.

gratuitious complexity.

...

The questions of pre-compiled headers/modules/C++11 subset of boost have nothing to do with outcome and shouldn't be included here. Focus on one and only one thing: The boost.outcome library. It's quite a small library and trying to make it carry the freight for all these other ideas will deprive it of the value it might have.

I'd like to. But it looks like accepting outcome into boost will effectively mean accepting a boat load of other unrelated stuff. So if you want to address just outcome, remove all the other stuff.

That would not be a widely held opinion. Most end users of Outcome don't want any Boost connection at all.

No problem. If you believe that don't submit it to Boost.

They do want excellent top tier cmake

support, with automatic usage of compiler technologies such as precompiled headers, These are available to users - not required to add to libraries C++ Modules, Not ready yet clang-tidy passes, don't know what that is. unit test All libraries support unit test without adding confusing stuff to their

LOL - which would require CMake being quality product - which I don't believe it is. library

dashboarding, not related to the library sanitisers, already supported. ABI guarantees, This is interesting and I might accept this. But but I'm not crazy about it being snuck in the back door. and lots of other goodies. nope

boost-lite provides lots of common cmake machinery used by all my libraries to save me reinventing the wheel for each. LOL - that's not what it looks like. I don't think library code should be tied to anything outside it.

Again, none of this matters to an end user who just wants to #include and go. You can do exactly this with Outcome. It neither uses nor interferes with anything in Boost. It is an excellent neighbour, including to other versions of itself.

Just because you don't understand the value of exception_ptr and nested exceptions doesn't mean you are in a majority. Nested exceptions support in the C++ 11 STL wouldn't be there unless WG21 thought them highly useful.

Right - I'm just relating the experience of one user - myself. But I don't think I'm untypical. I have to say I've never seen exception_ptr or nested_exception in any code. If you think this is important, you need to provide information on or at least point to references which describe how this stuff because most of us who don't read the standard text don't even knows it exists.

...

I expect to see type requirements (aka concepts) for T and E. Can any types be substituted? It's a mystery. Hmmm maybe initial example and/or looking at the source code will be useful. First of all, the example has no #include or some such. I go looking for that and .... I can't find it. It's somewhere hidden through a maze of ... preprocessing?

There are static asserts which fire if the types used don't meet their requirements.

LOL - so one doesn't know what the requirements are until you compile the code? How can write code this way?

You are correct they are not documented in the reference API docs. There is an open issue to fix that.

OK - but

...

...

- What is your evaluation of the implementation?

Needs to be slimmed down and all the extraneous stuff removed. This isn't a vehicle for upending boost. This is trying to get as modest simple header only library into boost in a way which makes it useful to users nothing more.

As I have said many times now, end users can #include and go.

That's certainly not apparent from the examples.

They don't care,

LOL - this user cares nor need to care, I'm not convinced of this.

how the implementation works so long as it cannot cause them misoperation.

Up to a point this is true. But for a simple type such as this one I have some expectation what the implemenation should look like and when I look here - I can't see anything that makes much sense to me.

...

If one thinks I'm being two harsh, I propose the following experiment: Take a pair of left over interns from C++Now and direct them to the outcome git hub package. Give them a simple task to use the outcome library. See if they can complete it in one hour or less.

I have seen completely uninitiated users get up and running with Outcome in less than five minutes.

Honestly I can't believe this. I would have to see it for myself.

If the end user has programmed in Rust or Swift before, they just need to be told:

#include "boost.outcome/include/boost/outcome.hpp"

boost::outcome::expected

... and they're good to go.

LOL - I'll start learning Rust so I can use outcome.

...

On the other hand, I believe it wouldn't be too tough to take the pieces of this library already made and compose them into a more tightly focused package that would fit into boost in a natural way that users would useful and easy to use. But the look and feel of the package would be entirely different than the current one so It would really have to be reviewed again. I also believe that if the package were re-formulated as I suggest, the review process would be much, much less onerous for everyone involved.

Thanks for the review.

You're welcome Robert Ramey

Niall