Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

...

No, nor do I think it matters. The rationale to use Outcome for me in my code is to let the caller decide whether an exception should be thrown or not, rather than the function experiencing the failure hard coding an exception throw which invokes an unavoidable table search I'd like to avoid. That's my primary use case in my own code.

But look like your rationale is different than the motivation section in the documentation. Maybe this is a communication problem. Again we may have failed in communicating to the people what this library is not.

Do bear in mine the qualifier "for me in my code". I don't claim, nor would I claim, that my need case is anyone else's or ought to be. Hence the present formulation of the tutorial.

...

My secondary use case is that rather than encode the logic for how to type erase/rethrow/convert the failure into an exception throw via a preprocessor macro which is how it's usually done e.g. BOOST_THROW_EXCEPTION(), I'd like to set rules via the type system for what is to happen. No macros needed. The policies are very useful for this use case.

But there is one notable inconvenience. Two different policies applied in two different places render two different instances of `result<T>`. These instances are not inter-convertible (or am I wrong) and you cannot use them freely together.

Implicit construction is only permitted when value_type and error_type and Policy are the same. Explicit construction is permitted when A::value_type is constructible to B::value_type and A::error_type is constructible to B::error_type. Policy is ignored. ValueOrError construction is permitted when the input is (by the default rules) a foreign type but whose value_type and error_type are constructible to the local type's. Policy has no (default) role here. So, to answer your question, Policy only matters for implicit constructions only, and is otherwise ignored. We trust that if the programmer is doing an explicit construction, they know what they are doing. This applies to the default out-of-the-box rules. One can override the significance of Policy for a custom rule for type X doing a ValueOrError construction into type Y.

No copy elision. C++ 17 appears to allow the compiler to elide converting construction according to the usual copy elision rules. I say this only from examining assembler, I don't know what the standard says.

I think what Emil meant is that if one library you use reports `result` and another reports `result` you do not have a good type to return from the code that combines the two. Unless you apply a translation, but this way you loose information.

There's always `result>`. But otherwise yes, this is on the programmer to solve. Many techniques available, everything from logging to chaining to TLS to type erasure to throwing an exception. I don't see any of this line of argument as a good reason to reject a library just because some people might misuse it, or go too far with it, or do something stupid with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/