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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-25 04:05:16

On 04/25/2013 12:08 AM, Gottlob Frege wrote:
> On Wed, Apr 24, 2013 at 5:29 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> 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?
>>
>>
> Sorry, I must have been thinking of a different Alexandrescu class.  He
> has/had an error class where if you didn't read the error, it threw in the
> destructor.  I was inadvertently mixing the two concepts together.
>
>
>
>>
>>>
>>>
>>>>   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
>>
>>
>>
> I'm just thinking that having the error be an exception is too specific.
>   I'd prefer a single class where the error might just be an error code, or
> might be a full exception of some kind.  *If* we could give it reasonable
> behaviour for both cases.  (Or compromise.)  Otherwise we have multiple
> expected_* classes, which I think lowers the value of each (in this case).
> Maybe separate classes is best, but I suspect that a single class would
> have a better chance of eventual standardization.
>
> But I should probably just stop commenting, and wait and see what comes out
> of this.  I'm having a hard time (and have a lack of time) following this,
> so once the class is more concrete it should be easier to discuss.
>
> Tony
>

If we want to stick to a single class, I think that the expected<T> 
containing a std::exception_ptr is best. Why ? Because it enables cool 
features with current_exception and because the standard provides 
exception classes even for error code. The new 
error_condition/error_code class can be wrapped into system_error which 
is an exception. That's mean that the standard provides exception 
classes even for error code. If we take that into account, I think 
expected<T> with exception inside is enough. For non-standard error 
code, the user can easily wrap an error inside an exception (even if the 
user never thrown). We could provide facilities for wrapping error code 
inside exception too.

If you think I'm right, I'd like to focus my proposal on such an idea. 
Time is missing (at least for the GSoC), and I must hurry up.

Thanks for the great discussions,
Pierre T.