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

4 Jun 2017

      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 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 is 
implicitly constructible from unexpected_type<E>. This avoid this kind 
of ambiguities.

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

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

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