Re: [boost] [outcome] Review of Outcome

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 is exactly the right object for you.

It seams Emil has a use case for empty or T or exception_ptr :( Vicente