Boost logo

Boost :

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-09-13 08:14:07

> Well, throwing an exception is not the only reasonable choice here. For
> instance, some people use the STL compiled in -no-exceptions mode. In such
> case, in any place where normally an exception would be thrown, function
> `abort()` is called instead. For uniformity, these users might expect
> Outcome to also call `abort()`. `abort()` is not an UB: it is predictable,
> and drastic as it is, it can still be considered as means of handling
> errors. For instance in a video game: if it occasionally crashes, it is
> acceptable.
Then maybe define the policy function for creating an exception like this:
- if it is not defined: value() cannot be called
- if it has void return type then call terminate/abort (maybe require a
trait instead?)
- if it has a non-void return type, throw this
> The "value() always wide, assume_value() always narrow" solution appears
> very clear and easy to explain, however it might turn to be not acceptable
> for social reasons. Name `value()` sounds attractive and users want to use
> it by default: both the users that compile with no-exceptions, and the
> users who wan to us exceptions and the `fun().value()` idiom.
IMO reasoning about code is more important than brevity. As already
mentioned: When doing a code review you may see: `if(result)
You may conclude that this is wrong/superflous until you learn that the
policy for this result type defined anywhere anyhow allows this. Then
you see a non-guarded `result.value().use();` and may (wrongly) conclude
it is correct as it throws, but it doesn't.

In the end the solution is very easy: "users that compile with
no-exception" use a terminate-on-valueless-value()-policy and the
`if(result) result.value().use();` usage. Note that the `value()` will
have the same valueless-check as done by the `if(result)` and will then
be eliminated by the compiler. So they ALWAYS have correct behaviour
(forgetting the if will terminate) and the nice looking code. See also for why omitting the range check in
string/vector operator[] was/is a mistake.

Boost list run by bdawes at, gregod at, cpdaniel at, john at