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

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
>>>> destructor
>>>> 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
>>>> forgot
>>>> 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
> cases.
>
> Best,
> Vicente
>

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

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,
Pierre T.