Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-25 03:20:01
On 04/24/2013 11:29 PM, Vicente J. Botet Escriba wrote:
> Le 24/04/13 19:49, Gottlob Frege a écrit :
>> On Wed, Apr 24, 2013 at 12:47 PM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>> Le 24/04/13 18:02, Gottlob Frege a écrit :
>>> One thing I missed in this conversation:
>>>> Are we considering the Alexandrescu behaviour of throwing in the
>>>> if the expected<> has not been read?
>>> Why would you want to that?
>> I didn't say I did, but some might. And the Alexandrescu version (which
>> was referenced as one design) works that way.
> I didn't understood it this way. I've checked the slides and I have not
> found nothing about the destructor. Could you point me where have you
> found that the destructor throws if the value were not read?
>>>> I was imagining just an excepted<likely_type, error_type> class. I
>>>> about the novel throwing behaviour.
>>> This will correspond to expected_or_error.
>> I'm hoping for just one class, not multiple.
> I didn't catch that you were suggesting to have
> template <typename T, typename ExceptionalType= std::exception_ptr>
> class expected;
> Humm, this could be done, but the has_exception function has no sense if
> the ExceptionalType is not exception_ptr.
> But a get_exceptional and accept_exceptional_visitor have sense in both
That's sound weird to me. The fact that ExceptionalType is a
std::exception_ptr enables specific behavior in many functions such as
the expected::get(): if ExceptionalType is a std::exception_ptr it
throws, otherwise (pick up your favorite):
* it does nothing (undefined behavior);
* it wrappes the ExceptionalType into an exception.
Also with the default constructor, with exception it captures the
current exception, otherwise I guess the expected class shouldn't have a
Or again the factory make_noexcept_expected(F&& fun); that is relevant
only if ExceptionalType is an exception.
I totally agree that expected would be better with only one interface.
But, IMHO, we would move out the cool features and the expected class
would look like a variant with specific semantic.
Thanks for all the great comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk