Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-30 21:28:17

2017-05-30 18:11 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> 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.
>
> If everyone is typedefing their own varieties, this doesn't provide a
> standard infrastructure. Sure, it would be useful for people who control
> all of their code, but no more than that.
>
> There should be one and only one result<T>, and one and only one
> outcome<T>, with those names, which the world should use.
>

I support this. I like the initial choice of this library. What percentage
does this make of people wanting one outcome and one result?

>
> Let's first see if people who favor a narrow interface are satisfied with
> value_if, which for me is a very good compromise. Once you have a raw
> pointer, things are as narrow as it gets.
>

I'll respond to this separately.

Regards,
&rzej;