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

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

expected is convertible to expected, where all error types in `E1...` also occur in `E2...`. So it follows that expected<T> is convertible to expected for any `E...`. That is, you can `return expected{ x }` in a function returning expected.

I don't see how expected could default to expected?

It doesn't default to anything, no.

Does it mean that we need an additional template alias

template using expected2;

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

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

Yes, I suppose you could do that. I agree that unexpected_ 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.alg...

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, an alias for std::integral_constant. 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 and get 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.