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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-16 14:59:27

> 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

... and so on. C++ 11's error_code's `if(ec) ...` doesn't handle these,
and as Chris mentioned, it was never designed to do so. Though
error_code itself handles them perfectly fine.

Originally, `if(ec)` meant "if error code". Of course, recent C++ isn't
so sloppy anymore, we no longer should write `if(x)` when we mean `if(x
!= 0)`. And clang-tidy et al warns now appropriately.

That cultural shift in best practice is part of the cause of this debate
with `if(ec) ...`. The programmer is writing that, and usually expecting
it means something that it currently does not. After all, testing a
smart pointer by boolean check means "is the smart pointer pointing to
something?"

So are we reaching a consensus towards or away from the proposed change?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/