Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-30 21:18:14

Vicente J. Botet Escriba wrote:

> I believe Peter want a Result type independently of what the standard will 
> provide one day, and he wants it now and not in 2020. Maybe this Result 
> type could one day a candidate for the standard. Could you confirm, Peter?

As I see things, we have a very good std::error_code infrastructure sitting 
(underused) in <system_error>, we have a good outline of how it's used in 
<filesystem>, and there we have the whole API doubled as in

    void api_function( ... ); // throws system_error
    void api_function( ..., error_code& ec ); // doesn't throw

for example

    bool exists( const std::filesystem::path& p );
    bool exists( const std::filesystem::path& p, std::error_code& ec ) 
noexcept;

I also see that an std::result (or std::outcome, or std::result with outcome 
semantics as per Emil) would allow us to express that as

    std::result<bool> exists( const std::filesystem::path& p ) noexcept;

with no apparent loss of functionality. (*)

Getting people a library that has a multitude of result classes would 
obviously be better than nothing, but how would it move us toward the goal 
of having std::result?

How Boost originally worked was, when there is disagreement as to how some 
component should work, we hammer out our differences here, produce a 
consensus design, produce, as a result of our process, a rationale of why we 
arrived at this consensus and how, get the library into the hands of our 
users, listen to their feedback, refine as necessary, then hand the finished 
product to the LWG.

When some people want X, others Y, a third group Z, it's always the path of 
least resistance to just put X+Y+Z into the library, or a policy-based 
factory that can create 6^11 classes, among them X, Y, and Z. But that's 
really a cop-out.

(*) Not quite because the straightforward implementation would throw 
system_error instead of filesystem_error on value() and we'll lose the path, 
which is an interesting angle that we need to explore.