Boost logo

Boost :

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-09-13 07:50:48


> *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".

> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk