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/