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

Subject: Re: [boost] expected<T, E...> (Was: [outcome] High level summary of review feedback accepted so far)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-04 15:27:09

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<T, error_code>
I understand that when designing expected<T, E...> 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<T,E...>?
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<T, E...> could default to expected<T, error_code>?
Does it mean that we need an additional template alias

template <class T, class R = error_code>
using expected2<T, E>;

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<variant<int,string>, 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.algorithm.mp_with_index_n_i_f 
>

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<mp_size<expected>>( 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<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.

For the standard this *could* be good, but will your library be C++17 only?

Vicente