Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-05-30 16:34:37
On Tue, May 30, 2017 at 9:11 AM, Peter Dimov via Boost <
boost_at_[hidden]> 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.