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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2018-01-16 20:00:55

Le 16/01/2018 à 15:59, Niall Douglas via Boost a écrit :
>> 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 
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.