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

On Sun, Jun 4, 2017 at 12:35 PM, Peter Dimov via Boost 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 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, 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 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 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