Re: [boost] Reforming Boost.System and <system_error> round 2

...

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 can be seen as expected, 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 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. 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.