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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-04 22:12:52

Le 30/05/2017 à 23:18, Peter Dimov via Boost a écrit :
> 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. (*)
We have yet some trouble with constructors. We need factories instead :(
>
> 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.
If we want to be able to throw a specific exception, we need to ensure a 
single mapping from E to Exception. We can do it in two ways

Wrap E so that the conversion to Exception can be done, e.g. instead of 
std::result<bool> we could have expected<bool, filesystem::error_code>
filesystem::error_code is a wrapper for error_code that defines the 
rethrow function throwing filesystem_error.

Again the problem is that now we need to unwrap filesystem::error_code.

Vicente