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

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

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 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

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.