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

Le 23/04/2013 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.

...

Hello, std::expected 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 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.