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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-04-24 18:08:11

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