Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at