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

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-02-04 01:10:13

>> 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<T,
> E1>` and another reports `result<T, E2>` 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<T, variant<E1, E2>>`. 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/