Niall,
What do you think about the following alternate interface of outcome types?
1. Remove option<T> altogether.
2. result<T> (and outcome<T>) does not have a separate empty state.
3. A default-constructed result<T> is initialized as if
`result<T>{error_code_extended{}}`.
4. Function r.empty() is implemented as `r.has_error() && !error()`.
5. Framework requires that type E in `expected` is
default-constructible, and its default-constructed value represents no
error condition (already the case for exception_ptr, error_code).
The rationale behind this is my assumption that `option<T>` is not as
useful as the other types. (Or can you give an example to the contrary?)
That there was no initial business need for an empty state, and the
examples that illustrate its usefulness are just exploring how we can make
use of it now that it is there. (Or am I wrong here?)
I noticed a number of people report negative feedback about this empty
state. Getting rid of it would take result<T> closer to "either T or reason
for failure".
What do you think?
Regards,
&rzej;
