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

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-30 20:55:44

2017-05-30 16:01 GMT+02:00 Dominique Devienne via Boost <
boost_at_[hidden]>:

> On Tue, May 30, 2017 at 3:51 PM, Niall Douglas via Boost <
> boost_at_[hidden]> wrote:
>
> > On 30/05/2017 13:25, Peter Dimov via Boost wrote:
> > > Niall Douglas wrote:
> > > There is a middle ground here, which I was pondering for a while, make
> > > has_value return T* instead of bool.
> >
> > It's a clever idea, but it reminds me too much of C++ 98 days of
> > returning void * and such to implement boolean testing. We all got badly
> > bitten with those tricks
>
>
> But that was mostly from implicit conversions though, while here it's an
> explicit method call.
>
> My concern is more that I expect a has_value() method to return a boolean,
> not a pointer.
> value_if() OTOH is elegant, almost self-explanatory, and the if(auto* p =
> o.value_if()) idiom
> is quite readable, despite the two ifs. FWIW. --DD
>

Another name for the function could be `try_value`. But I can still see one
use case, where it feels strange. I have just created an `expected`
containing a value. Now I want to refer to it directly:

```
expected<vector<T>> mahe_vec()
{
  expected<vector<T>> ans {value}; // creates an empty vector in-place
  vector<T> & vec = ans.value();
  // ...
}
```
Niall has indicated a number of times that the second defensive if is
removed in context like the following:

```
if (ans.has_value())
  ans.value(); // second check elided
```

But in my case with `vector` there is no first check, but I am still sure
the value is there because I can trace the entire (quite triviall)
life-time of the object. Using value_if is possible, but:

```
expected<vector<T>> mahe_vec()
{
  expected<vector<T>> ans {value}; // creates an empty vector in-place
  vector<T> & vec = *ans->value_if();
  // ...
}
```

It doesn't indicate what I am doing clearly enough. If I had a
narrow-contract accessor, it would read clearer:

```
expected<vector<T>> mahe_vec()
{
  expected<vector<T>> ans {value}; // creates an empty vector in-place
  vector<T> & vec = ans.just_value();
  // ...
}
```

Returning a pointer actually only superficially looks like you are
protecting yourself from the narrow contract. You just force the caller to
use narrow contract function on the pointer.
This reminds me that at some point people here in Boost discussed that
get<T>() accessor on variant<T, U, V> should return optional<T&>.

Regards,
&rzej;