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

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