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

4 Jun 2017

      Le 04/06/2017 à 12:53, Peter Dimov via Boost a écrit :
...
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.)
But make_expected() returns expected
I understand that when designing expected we need to reconsider 
some functions.

BTW, to what it is useful to have a expected<T> without a possible error?
is expected<T> convertible to expected?
This would be nice.

Then if I make the expected constructor from T explicit we have two 
explicit factories one for success and one for failure (I know most of 
you don't like it).

I don't see how expected could default to expected?
Does it mean that we need an additional template alias

template 
using expected2;

How constructor guides will play here?
...
...
* 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.
expected, int, string> ?
unexpected_type<E> was used for that to avoid ambiguity.
...
...
* 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.)
Point taken.
...
...
* Additional throw_on_unexpected
This translates the E types into exceptions, as I explained in the doc.
I see that this is a customization point. My proposal has an open point 
to be able to configure the exception to throw via a traits. I'll add 
yours as possible approach.
...
...
* 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.alg...
I don't see it yet. What is the type of I. How can you use a function 
parameter as a template argument?

         return mp_with_index( v_.index(), [&]( auto
I // fct parameter
) {
             return this->_remap_error<R>( I, f, get<
I // templ argument
...
(v_) );
...
* ::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 from 
expected.
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.
For the standard this *could* be good, but will your library be C++17 only?

Vicente