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