
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.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<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