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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-04-25 16:38:31

On Thu, Apr 25, 2013 at 4:05 AM, Pierre T. <ptalbot_at_[hidden]> wrote:

>
> 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.
>
>
I think you should do whatever you think is best.  At least get started
down that road.  It always can be (and will be) tweaked later.

I would just like to keep in mind *some* way for the simple 'error code'
case to be handled (and I don't mean std::error_code, which looks too
complicated or not appropriate for custom errors).  ie a simple wrapper

enum MyErrors
{
   PrinterOnFire, DeveloperGoneInsane, ....
};

expected<string, simple<MyErrors>> getName();
or
expected<string, MyErrors, SimplePolicy> getName();

or, if the default is *non* exception based, then allow a way to do the
exception case:

expected<string, MyErrors> getName();  // non-exception

expected<string, as_exception<MyErrors>> getName();
or
expected<string, MyErrors, ExceptionPolicy> getName();

etc.

Just do whatever you think is best, and I'm sure a reasonable path will
show itself somewhere along the way.

Tony

(the last one is implying that the default is non-exception-based, and
requires