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. (*)
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.
