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: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-04 20:13:35

On Sun, Jun 4, 2017 at 12:35 PM, Peter Dimov via Boost
<boost_at_[hidden]> wrote:
> Vicente J. Botet Escriba wrote:
>>
>> What do you think of making expected constructor from T explicit?
>
>
> That's one of the options. Another is to make
>
>>     expected<double, unscoped_error> test()
>>     {
>>         return unscoped_other_error;
>>     }
>
>
> work and return an error, instead of a double (exact match to E).
>
> I know that there are people who insist on explicit everywhere, but implicit
> does have its appeal.
>
> Of course in pathological examples such as expected<variant<int, float>,
> int, float>, implicit conversions will rarely do what one wants. But I'd
> argue that these (IMO atypical) uses should not carry much weight.
>
> expected<double, int> is a more likely case, and there's no way to make
> implicit conversions always do the right thing for it. I'm not sure how much
> we ought to focus on it.
>
> Perhaps the heuristic could be, if the argument can be interpreted as both a
> value and an error, the conversion is ambiguous, regardless of which of the
> two is a better match. This will make the above return ambiguous, which is
> probably as it should be.
>

I think I might agree with that.
There will definitely be cases where expected<T,E> has T == int and E == int,
and worse, sometimes those cases will be:
- T is a template param, so you don't "see" that it is sometimes an int
- E is a #define or platform-defined, etc, so it is only _sometimes_ an int

Tony