Re: [boost] [outcome] narrow-contract, wide-contract, and value_if

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 
about expected.)

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