On Tue, May 30, 2017 at 9:11 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Niall Douglas wrote:
1. I have been persuaded to use longer more appropriate naming for result<T> and outcome<T>, so now the typedefed varieties with implicit conversions to their empty-capable form indicated by "=>" are:
- static_checked_outcome<T> => static_checked_optional_outcome<T> static_checked_result<T> => static_checked_optional_result<T>
...
- runtime_checked_outcome<T> => runtime_checked_optional_outcome<T> runtime_checked_result<T> => runtime_checked_optional_result<T>
...
Nobody is proposing that end users actually type out the full name each and every time they use them, and the documentation will make that clear.
As I already said, for me this takes away the whole point of the library, which is to provide STANDARD result types which people use in their public APIs.
+1 This is not unlike function<> and shared_ptr<>, what makes those types useful at all in interfaces is the same thing that makes pointers useful in interfaces: a T * is a T * and there aren't different kinds. I don't even like having both outcome<> and result<>, if I understand correctly the reason they exist is to remove perceived inefficiencies in exception_ptr implementations. I understand that this may be important in a library motivated by perceived inefficiencies in exception handling, but it seems wrong to write a library to work around flawed language implementations, inefficiencies which clearly do not exist in the language definition.