Re: [boost] [outcome] Review of Outcome

Subject: Re: [boost] [outcome] Review of Outcome
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-29 11:12:20

Le 29/05/2017 à 01:46, Niall Douglas via Boost a écrit :
>> In my opinion the library should drop option<T> and result<T> altogether
>> and should be reduced to outcome<T> only, which can be empty, or hold a T,
>> or hold an exception (but not error code, see below.) This is critical for
>> a library that aims to provide a _common_ general mechanism for dealing
>> with failures in interfaces; providing a rich set of alternatives works
>> against that goal.
> As was covered in the FAQ, outcome<T> may store an exception_ptr, which
> is implemented using atomics. This causes the compiler to emit a lot
> more code than a result<T>, which is why we have a result<T> with
> implicit conversion on demand to an outcome<T>. If one uses the least
> representative type possible, one gets minimum code bloat and maximum
> performance.

Why do you need atomics?
>
>> Secondly, it is not a good idea to use error codes or any other value as
>> means to dispatch on different kinds of failures because semantically such
>> dispatch should be static: there is some _code_ which detects the error,
>> and there is some other _code_ that needs to bind it and handle it. This is
>> one reason why in C++ catch dispatches by the static type of the exception
>> objects, not by some exception.what() value.
>>
>> Further, using static types to communicate different kinds of failures
>> allows users to recognize and handle an entire class of errors by means of
>> implicit type conversions, by organizing error types in a hierarchy. For
>> example:
>>
>> struct io_error: virtual std::runtime_error { };
>> struct read_error: virtual io_error { };
>> struct write_error: virtual io_error { };
>> struct file_error: virtual io_error { };
>> struct file_read_error: virtual file_error, virtual read_error { };
>> struct parse_error: virtual std::runtime_error { };
>> struct syntax_error: virtual parse_error { };
>>
>> With this hierarchy, we can use read_error to handle any kind of read
>> errors (not just file-related), file_error to handle any kind of file
>> failures (read or write), etc.
> If you favour using the type system to statically enforce error codes,
> then expected<T, E> is exactly the right object for you.
It seams Emil has a use case for empty or T or exception_ptr :(

Vicente