Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-09-13 08:03:27

czw., 13 wrz 2018 o 09:51 Niall Douglas via Boost <boost_at_[hidden]>
napisał(a):

> > *Having said that*, if I'm understanding correctly, this sounds like it
> > would mean that you won't be able to use a custom error_type with
> > Outcome unless you either:
> >
> >   1. Declare some "this is how you throw an exception for this
> > error_type" method (presumably a template specialisation?)
> >
> >   2. Only ever use it with some non-default policy (that either never
> > throws or has user-implemented code to throw).
> >
> > Is that correct?  (Or would #1 always be required regardless of usage?)
>
> Front line `result<T, E>` would become unusable with UDT E types yes. If
> people want UDT E types, they would need to use `result<T, E, Policy>`,
> `unchecked<T, E>`, or `checked<T, E>`.
>
> So what's being proposed here is that `result<T, E>` becomes strictly
> for E types which are convertible to error code or exception ptr only.
> Everything else fails to compile with a suggestion "please go use
> checked<T, E> or unchecked<T, E> for UDT E types".
>

Just for completeness, users will have a yet another option already
available today:

Specify customization points for your type UDT (funciton make_error_code())
and you can continue using `result<T, UDT>` with the default policy (which
will throw `system_error`).

Regards,
&rzej;

>
> > On the *other* other hand, it wouldn't be a silly idea to have a generic
> > "throw this error_type" method.  system_error itself was somewhat trying
> > to be that generic method, but with the caveat of only supporting plain
> > enum error_types.
> >
> > Perhaps boost::throw_error, which is expected to internally construct
> > an appropriate exception based on its argument type and then call
> > boost::throw_exception?
>
> Me personally I almost exclusively use Outcome in P1028 SG14
> `status_code` mode now. Far superior codegen. SG14 `status_code` permits
> arbitrary error coding types, and can throw arbitrary exceptions from
> those. Outcome in SG14 `status_code` mode delegates the exception
> throwing to `status_code`.
>
> I'm fairly sure a major games studio has rolled out SG14 `status_code`
> into its code. They seem very pleased with it. It does indeed produce
> very lovely looking assembler.
>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>