On January 19, 2018 1:02:10 PM EST, Robert Ramey via Boost
On 1/19/18 9:16 AM, Vinnie Falco via Boost wrote:
Nobody wants to write
if(ec == my_condition::success)
LOL - I want to write this.
When then can instead write
if(! ec)
Even in your own code you write `if(! ec)`:
And when I do I want to consider it a mistake.
If there are to be multiple success values, then a comparison is unhelpful. You'd have to test each success value, in turn, to determine whether the code means success. Given the current design, including the behavior of the default constructor, the sizeable number of zero-is-success error categories, and existing practice, using helpful names and conversion to bool is quite workable: if (error) if (!error) To support multiple success values, a redesign is needed. One must be able to ask whether an error_code contains an error or not, and that should be done with a single function call: e.g., is_error(). To avoid the virtual call into the category Niall suggested, many error categories can calculate the answer on construction without any complex mapping (such as zero is success), and that answer can be saved within the object. That means the (relatively small) overhead of a virtual call, and any other logic, is only needed for those multiple success value categories. It remains to be determined what the default constructor, if there should be one, should initialize the state to. Zero is only useful for zero-is-success categories.
Whether it was intended or not, established practice is to treat the bool conversion of error_code as false==success and true==failure.
It may be established, but it's not good practice. It's an example where implicit conversion SEEMS to make things simpler and more expressive, but it ends up making things more error prone.
That's only true when there are multiple success values or zero is not success. There have been few such cases in practice, I think. -- Rob (Sent from my portable computation device.)