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.
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.
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,
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk