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

4 Jun 2017

      Le 04/06/2017 à 22:40, Peter Dimov via Boost a écrit :
...
Gottlob Frege wrote:
...
...
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
On Sun, Jun 4, 2017 at 12:35 PM, Peter Dimov via Boost
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
T == int, E == int is not a problem, because it will always be 
ambiguous. The thorny case is E == int, T == something convertible 
from int, such as double, long, unsigned.
Lets imagine ofr a moment that we allowed implicit conversion from 
convertible to T and convertible to E as far as both constructions are 
not possible.

     expected test()
     {
         return unscoped_other_error;  // Compile Error as ambiguous
     }

     expected test()
     {
         return make_unexpected(unscoped_other_error);
     }

Then if we want to be more explicit, then we can use wrappers that force 
us to be explicit: expected_ and unexpected_ are wrappers that are 
explicitly constructible from the wrapped type and provide explicit 
access to the value.

     expected> test()
     {
         return unexpected_{unscoped_other_error};
     }

  Note that unexpect_<E> can not be implicltly convertible to E as 
otherwise we will have again an ambiguity.

If we want also to be explicit on T

     expected> test()
     {
         return expected_{3.0};
     }

The problem now is that we need to unwrap the wrapped types as the 
conversion is not implicit.

My original design with an implicit unexpected_type was to avoid this 
unwrap operation, and define getter for unexpected_type<E> and also for 
the wrapped E.

Given an expected that has the implicit constructors, we can build 
another expected_expl that has his constructors explicit and provide 
unwrapping operation.

The same can be achieve from a expected that has explicit constructors, 
we can define a expected_impl that has his constructors implicit.

Do we need both approaches? I don't know..

Vicente

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

Vicente J. Botet Escriba