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

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@wanadoo.fr> 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 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 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.