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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-04-23 16:43:51

On Tue, Apr 23, 2013 at 3:28 PM, Pierre T. <ptalbot_at_[hidden]> wrote:

> Le 23/04/2013 18:55, Gottlob Frege a écrit :
>
>   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 ?
>
>
I'd agree with that.

>
>> 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 ?
>
>
Yes. It is called "expected" after all.  You expect the value, not the
error.  And if there is an expect.is_valid() I expect it to be referring to
whether the value is valid, not the error.  Etc.  It is not called
"std::pair<Value,Error>", it is expected<Value,Error>.

IMO, at least.

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

I don't like special cases, but I can imagine checking at compile time
whether Error derives from std::exception or not.  But that means anyone
using their own (non-std) exception hierarchy, expected<Value, MyException>
doesn't give what they... expected.

One option would be
    expected<Value, Error, should_it_be_wrapped_when_thrown>

With the 3rd arg deciding whether to wrap or not - or
wrap-if-derived-from-exception.  Which could default any which way.

But I lean towards thinking that Error is rarely or never an exception - if
it was, why use expected<> at all? Just throw the exception.  I think of
expected<> as being used in places where you don't want to use exceptions.
ie if you have

     expected<int, SomeException> someFunction();

where someFunction() could *return* an exception, why not just

     int someFunction(); // throws SomeException

So I think I'd prefer it always to wrap.  ie assume that the Error is NOT
an exception, and not meant to be thrown.  The only time it is thrown is
when someone (mistakenly? ie coder error) accesses the value via
expect.value() and it throws bad_expected_access<Error>.  Or
"un_expected_access" :-)

>
> What others think about this behavior and interface ?
>
> Thanks for any comments.
> Pierre Talbot.
>
>
I'd definitely like to hear more from others.  Maybe I'm not imagining some
of the ways this is expected to be used.

Tony
(all puns are purely intentional.)