[boost] expected<T, E...> (Was: [outcome] High level summary of review feedback accepted so far)

Subject: [boost] expected<T, E...> (Was: [outcome] High level summary of review feedback accepted so far)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-04 10:53:50

Vicente J. Botet Escriba wrote:
> You have taken some deviations from the proposal that could merit 
> discussion
>
> * missing sizeof...(E) >0 assertion

expected<T> is valid. Its purpose is to make expected{ expr } valid (the 
equivalent of make_expected.)

> * unexpected_ type is not an explicit and different type

Could be done a different type, if this simple alias is determined to not 
work for some reason.

> * inheritance of bad_expected_access<T> from from bad_expected_access<> :)

That enables you to catch all bad_expected_access errors. Without a base, 
you have to enumerate every possible E, and some of them may not be known 
until run time (because dlopen.)

> * Additional throw_on_unexpected

This translates the E types into exceptions, as I explained in the doc.

> https://github.com/pdimov/variant2/blob/master/include/boost/variant2/expected.hpp#L174
> I suspect that this is is_move_constructible

Correct, copy/paste mistake.

> https://github.com/pdimov/variant2/blob/master/include/boost/variant2/expected.hpp#L334
> has_error/error should be defined only if sizeof... (E) is 1

In principle. I haven't gotten this right yet, hence the static_assert. The 
problem is that adding a template parameter interferes with 
has_error<E>/error<E>.

> * unexpected()/error() should have a narrow contract (but this needs to be 
> discussed in Toronto)

Please no.

> I don't see how get<I> can work here.

https://rawgit.com/pdimov/mp11/develop/doc/html/mp11.html#mp11.reference.algorithm.mp_with_index_n_i_f

> * ::then seems to be the monad::bind, could you confirm?

It's a monadic bind, yes. I'll remove .then in favor of operator>>, as 
documented.

> * Wondering from constructors from convertibles expected<T,E...> from 
> expected<U, G...>.

I'm not sure yet whether to enable value conversion. Pretty sure we don't 
want error conversions outside remap_errors.

> * Factories are missing

Since we have argument deduction now, expected{ expr } and unexpected_{ 
expr } can be used for the purpose, and I saw no need for separate factory 
functions.

> * I don't know if expected<void, E...> has been implemented

Not at the moment, although I intend to add it. It will basically change all 
T references throughout to void.