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

Le 23/04/13 18:55, Gottlob Frege a écrit :

On Tue, Apr 23, 2013 at 10:18 AM, Krzysztof Czainski <1czajnik@gmail.com>wrote:

...

2013/4/23 Pierre T.

It's what I called

...

expected_base in my previous mails, the get() on expected_base doesn't throw and if expected_base doesn't contain a value, then undefined I would expect an exception. behavior occurs.

Hmm, couldn't the original error be thrown anyway (if the wrapping type had a virtual function that would throw the error)?

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).

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.)

IMO, expected::value()/get() must throw the container Exception (if any). expected_or_error::value()/get() should throw bad_expected_access which would contain the error condition. bad_expected_access could share the design of future_error. Best, Vicente