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 15:37:53

Le 04/06/2017 à 14:40, Peter Dimov via Boost a écrit :
> Vicente J. Botet Escriba wrote:
>
>> * remap_errors seems close to what I've called adapt
>
> `adapt` is a good name. I may adopt it. (Or adapt to it.)
>
> There is one open question. With the given interface, with conversions 
> from T implicit and conversions from an error explicit, consider what 
> happens here:
>
>    enum unscoped_error
>    {
>        unscoped_other_error = 7
>    };
>
>    expected<double, unscoped_error> test()
>    {
>        return unscoped_other_error; // returns 7.0
>    }
>
> This seems undesirable. To prevent it, we either need to have both 
> explicit, or both implicit. I'm tending toward the latter (but if an 
> error type is chosen by the variant-like overload resolution, I plan 
> to static_assert on exact match.)
>
>
unexpected_type<E> is explicitly constructible from E. expected<T, E> is 
implicitly constructible from unexpected_type<E>. This avoid this kind 
of ambiguities.

With a variadic expected<T, E...> we need that it to be constructible 
from unexpected_type<Err> for each Err in E...

This would mean that unexpected_type<E...> or what you name 
unexpected_<E...> can not be an alias of variant<E...>.

Wondering if your example doesn't justify an explicit constructor from T 
as well.

This is how I see it. We can not agree.

Vicente