Subject: Re: [boost] [outcome] narrow-contract, wide-contract, and value_if
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-30 23:30:09
On 31/05/2017 10:36, Andrzej Krzemienski wrote:
> First, the wide-contract functions.
> We have a situation when someone assumes that `o` currently stores an
> error_code, and with this assumption in mind calls `o.error()`, but somehow
> his assumption is incorrect. What do we want to do?
> 1. Try to report programmer's bug at run-time?
> 2. Since in this case it is a bug anyway and are screwed, at least let's
> make such behavior useful for other situations where `error()` is called
> conciously on `o` without an error code?
Perhaps this is where our philosophical difference lies.
I don't consider calling error() a bug *at any time*, even if the object
does not explicitly contain an error_code.
An outcome is *not* a variant and does not have the same semantics as one.
(Having said that, this argument applies only to result/outcome, where
the error type is known and can be sanely constructed to indicate "no
error occurred". expected<T,E> can't make that assumption so it's much
more like a plain variant. This is actually one of the things I dislike
> The second scenario in a way ignores the bug, and lets the program
> continue, as though it was correct, and from now on the program is doing
> something else than what the programmer intended. But the semantics of the
> function are useful in itself. Users who check `o.has_error()` before
> calling it can use it as if `error()` had a single purpose and a narrow
> contract; and users who know the additional semantics can use it for other
> useful things, like saving themselves of writing some boilerplate code.
What if the programmer intends to get an error_code that indicates
success, perhaps for logging purposes? Like I said, this should not be
considered a bug in the first place, and the program *is* correct.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk