The semantics of this `if(ec)` is "conditionally well-defined": provided that you make sure that in all error categories you use throughout your program zero indicates success and non-zero values indicate failure, then (and only then) does this construct test if `ec` represents a failure.
Some programs can guarantee that, e.g. if they only use the default category on Unix. However there are plenty of C error coding schemes with many values for success e.g.
SUCCESS_QUOTA_LOW SUCCESS_SLOWPATH SUCCESS_VIA_BROKER I believe error_code shouldn't be used for this case. We need something else as a status_code type that conveys success/failure information. There is a standard proposal status_value that conveys a status and
Le 16/01/2018 à 15:59, Niall Douglas via Boost a écrit : optionally a value if the status represents a success. If we split a status on two types one for the success states and the other for the failure states, status_value<S,T> can be seen as expected<pair<Success<S>, T>, Failure<S>> but with a different representation. Note that when there is a single value for success, there is no need to represent it, as expected<T, Failure> IMHO, If we want to transport success states they must be transported on the success alternative, not on the failure one. Best, Vicente P.S. I know that this post is not about Outcome, but I believe the motivation comes from your Outcome design. I think it should be UB to use a success error_code with expected<T, error_code>. Not having the value and having an error_code that represents success has no sense for me. The ongoing standard proposal doesn't say nothing about E and I don't know what it could say.