Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: degski (degski_at_[hidden])
Date: 2018-01-28 15:12:18

On 28 January 2018 at 07:37, Niall Douglas via Boost <boost_at_[hidden]>
wrote:

> Sure, it's more manual and cumbersome, but it also means that the
> failure handling path has the same latency as the success handling path.
> And yes, if your EH implementation in the compiler is not table based,
> then there is not much performance gain.

 I take away the following from this:

1. Use of outcome is more manual and cumbersome, i.e. more error-prone.
2. *In certain setups* the failure path will have the same latency as the
success path.

Failure (when exceptions would be thrown) will in general be the result of
lack of resources (network-connection(s), memory, disk-space). The handling
of lack of resources (as I see it) would normally just try to stop the app
from doing more damage and to preserve a state (of data etc...), that is
hopefully valid. Logic errors just need fixing in my view, not exception
handled.

I, the client, am now in the doldrums (message on screen: "Oops, something
went wrong, call the IT dept. please!"). I don't see why this would need to
be fast, it will be slow in any case (Sorry, Niall is on his lunch-break!
Back in an hour.) and I (although I hate using them) agree with Emil D.
that exceptions is the C++ builtin mechanism to do just that (to save the
app from totally wrecking itself (its data)).

Exchanging Outcome for exceptions adds another lib I need to master (docs
took 4 months to write), adds complexity, adds ugly C-like macros (now we
finally have constexpr and noexcept) and ICE-es compilers. The objective of
the exercise is to avoid the "slow path". The cost of using exceptions (in
the success path) is a contentious issue, to which there doesn't seem to be
a consensus view. If the cost of the failure path is an issue, you're doing
something wrong, I think.

The fact that the current implementation ICE-es even the most current
compilers, means that it's usefulness will take years to materialize. First
for compilers to catch up and then the users, as people (and companies)
generally are conservative and seem very reluctant to move forward. I don't
understand why people prefer old bugs over new bugs, as newer bugs have a
better chance of getting fixed, once reported.

degski