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: Peter Dimov (lists_at_[hidden])
Date: 2017-06-04 15:55:50

Vicente J. Botet Escriba wrote:
> > 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...>?

expected<T, E1...> is convertible to expected<T, E2...>, where all error 
types in `E1...` also occur in `E2...`. So it follows that expected<T> is 
convertible to expected<T, E...> for any `E...`.

That is, you can `return expected{ x }` in a function returning expected<X, 
E...>.

> I don't see how expected<T, E...> could default to expected<T, 
> error_code>?

It doesn't default to anything, no.

> Does it mean that we need an additional template alias
>
> template <class T, class R = error_code>
> using expected2<T, E>;

We could call this alias... `result<T>`! :-)

> expected<variant<int,string>, int, string> ?
> unexpected_type<E> was used for that to avoid ambiguity.

Yes, I suppose you could do that. I agree that unexpected_<E...> should be a 
distinct type. For now I've taken a shortcut, but this will be fixed.

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

The type of I is mp_size_t<I'>, an alias for 
std::integral_constant<std::size_t, I'>. Since integral_constant has a 
constexpr conversion to its value, it can be used directly as if it were the 
compile-time value (modulo compiler bugs.) So get<I>, get<I.value> and 
get<decltype(I)::value> all amount to the same thing. C++14 is magic.

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

For a library that targets C++20, it does seem reasonable for the proposed 
interface to be optimized for C++17. If this becomes a Boost library, I 
could include make_expected and make_unexpected to ease C++14 use, but I 
don't think we need them in the formal proposal.