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: Peter Dimov (lists_at_[hidden])
Date: 2017-05-30 16:11:45

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.

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.