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 )
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk