2018-01-16 15:59 GMT+01:00 Niall Douglas via Boost
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?
How about annotating the conditional conversion to bool deprecated? It still compiles and works as before, but with compiler flag `-Werror=deprecated` can be turned into compiler error on demand, and then you are forced to rewrite to either: ``` if (ec.value() != 0) ``` or: ``` if (ec.failure()) ``` ? Regards, &rzej;