Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-23 15:28:00

Le 23/04/2013 18:55, Gottlob Frege a écrit :
> On Tue, Apr 23, 2013 at 10:18 AM, Krzysztof Czainski <1czajnik_at_[hidden]>wrote:
>
>> 2013/4/23 Pierre T. <ptalbot_at_[hidden]>
>>
>>> Hello,
>>> std::expected<int, Exception> exp;
>>>
>>>>
>>>> int x = exp.value(); // has no value - does this throw
>>>> bad_expected_access,
>>>> or does it throw Exception()?
>>>>
>>>>   Actually, expected contains an error and we don't know anything about
>>> the type of the error so we cannot throw it.
>>
>
> We can throw anything we want.  I'm not sure it is a good idea, but you can
> throw anything.  It doesn't need to derive from std::expection, for
> example.  You can throw an int. etc.
>
Of course, but I guess it's a bad practice ?
>
>> It's what I called
>>> expected_base<T, Error> in my previous mails, the get() on expected_base
>>> doesn't throw and if expected_base doesn't contain a value, then
>> undefined
>>> behavior occurs.
>>>
>>
>> Hmm, couldn't the original error be thrown anyway (if the wrapping type had
>> a virtual function that would throw the error)?
>>
>> Regards,
>> Kris
>>
>>
>
> I think we'd like to avoid virtual functions.  I'm not even sure the base
> class is needed.  I think we only want one expected<>, not 2 or 3 variants.
> (Although maybe I don't understand what all the variants are, I haven't
> looked at it thoroughly.)
>
>
> What we did for optional<> is allow you to access the value in 2 ways:
>
> optional<int> oi;
>
> int x = oi.value(); // throws bad_optional_access
> int y = *oi; // undefined behaviour
>
> Similar to vector [n] vs at(n).
>
We could use something similar in expected. But we must keep in mind 
that expected has a value and an error, is it clear that *expect return 
the value and not the error ?

> I think expected<> should work the same way.
>
> The only question, to me, is what it throws.  Either it throws the Error,
> or it throws bad_expected_access.  Or it throws bad_expected_access<Error>
> which derives from bad_expected_access_base, or something like that.  (ie a
> well defined exception, but I can still get my custom Error value back from
> it if I want.)
>
> Tony
>

I guess that the idea of error_wrapper_exception<Error> is interesting. 
Mainly because it enables us to have an unique variant of expected. 
However, if Error is an exception, it shouldn't be encapsulated into a 
error_wrapper_exception.

What others think about this behavior and interface ?

Thanks for any comments.
Pierre Talbot.