Re: [boost] [outcome] On the design and documentation

Subject: Re: [boost] [outcome] On the design and documentation
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 23:01:18

> First of all, I don't agree with the strong (conceptual) relationship between 
> optional (be it boost:: or std::experimental) in such a way that expected is a 
> generalization of it. From what I understand, the purpose of expected/outcome/
> result is to be used as a mechanism to return the result of a function. As 
> such it should also expose the semantics of it. Fortunately, we already have a 
> (asynchronous) return object standardized (std::future). And this is my basic 
> disagreement here: Why not model expected in the lines of future? With the 
> main points being: 

An earlier edition of Outcome did implement future-promise. I think you
yourself reviewed it then.

>  - expected being movable only
>  - expected<T,E>::value() should always return by value and invalidate this.

As I mentioned in a reply to Peter yesterday, I am attracted to these
semantics.

> Second, I think Niall raised a valid about outcome being a framework for 
> interoperability (completely orthogonal to the first point). However, I totally 
> miss this from the proposed library, most pressing are non intrusive 
> mechanisms. For that purpose I postulate, that a mechanism to transform 
> between different unexpected results, that is: various error codes etc.
> However, for that to work, one would of course need a properly defined concept, 
> for example, as Vicente suggested "EitherValue", and a mechanism to coerce one 
> error type into another, maybe through ADL, or traits specialization or 
> whatever.

<system_error> already provides equivalence testing between
std::error_code's.

> Furthermore, I believe that .value/.error should really have a narrow 
> contract, that is that it is UB to call those functions if the respective 
> types are not held (easy to catch this in a debug build...). Why? Probably 
> just a micro optimization, but consider the canonical usage:
> auto r = some_function_returning_expected(...);
> if (r.has_value())
>     // Do something with the value
> else
>     // An error occurred, PANIC
> In both branches, we know exactly what's in there ... so why check again when 
> getting the state out?

If you've already checked by hand, the compiler will elide the internal
check entirely.

> I don't get the "reinterpret_cast" argument. I am one
> of the persons that believe that UB is a necessary evil for some 
> optimizations...

I am not keen on sprinkling reinterpret_cast everywhere. But it appears

> When I open its "landing page", I get no idea about the following:
> - What is the purpose of the library?
> - Why/when should I use it?

It quite literally tells you both on the landing page.
https://ned14.github.io/boost.outcome/index.html.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/