Boost logo

Boost :

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.

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at