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 16:08:25

Le 04/06/2017 à 17:55, Peter Dimov via Boost a écrit :
> 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...>.
Great.
>
>> 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>`! :-)
Sure, and what about alias and factories.
>
>> 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.
Glad to see we agree.
>
>> >> 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.
Wow, I didn't was aware of this possibility.
>
>> > 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.
Agreed. the standard and Boost needs two different libraries.

What do you think of making expected constructor from T explicit?
What we lost by making it explicit?

Implicit use
    expected<double, unscoped_error> test()
    {
        return unscoped_other_error; // returns 7.0
    }

Explicit use
    expected<double, unscoped_error> test()
    {
        return expected{unscoped_other_error}; // returns value 7.0 // 
make_expected
    }

    expected<double, unscoped_error> test()
    {
        return unexpected_{unscoped_other_error}; // returns Error 7 // 
make_unexpected
    }

Vicente