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
, 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