2018-01-16 19:58 GMT+01:00 Andrey Semashev via Boost
On 01/16/18 21:22, Robert Ramey via Boost wrote:
I don't think it's just for the sake of churn. I think it's to improve program correctness by replacing ambiguous and opaque implicit behavior with unambiguous explicit behavior which is obviously correct on it's face without having to go look it in some documentation or source code somewhere else.
There's nothing ambuguous about the conversion operator, as it is specified in the standard, and I find the syntax quite intuitive.
I disagree here. The sole fact that we are pursuing this thread proves that contextual conversion to bool for error_code is ambiguous. You get professional programmers that were convinced or expect that this conversion tells failure from success. You have others that say they have designed error_code with the intention in mind that 0 has nothing to do with "success". The fact that its semantics are clearly described in the standard does not resolve ambiguity or error prone-ness.The semantics of the following code are also well defined: ``` int i = f(); // ... if (i = 0) // just one = i = g(); ``` Maybe I know what I am doing. But compilers nonetheless chose to issue a warning here, because it is _likely_ that the program does something else than intended. I am looking at the problem from the perspective of a programmer that works on the same code base with 20 other programmers. When I review the code I need to know what the intentions of my colleague was. I need it expressed so that I do not have concerns whether he is doing it deliberately or accidentally. You say you find the syntax quite intuitive. But do you also find the semantics intuitive? When you type or read `if(ec)` do you interpret it as "if operation failed" or as "if operation returned code of numeric value zero, regardless of the domain and regardless of whether in this domain zero means success or failure"?
You're not improving correctness by replacing it with a regular method. Instead, you're adding verbosity.
It is not about correctness, or rather not directly about correctness. It is about stating your intentions unambiguously in the code. So that it does not only compile to the correct code, but also clearly communicate your intentions.
Whether that is a good thing or not is a matter of taste. Personally, I choose the shorter syntax in this case.
True, in the end it is just a choice.
Also, simply replacing one construct with another doesn't "fix" the code.
True, but it is not about "fixing", it is about expressing your intent. Given that conversion to bool has semantics confusing to many programmers, and that there will be a reluctance to change it for the fear of breaking backwards compatibility or degraded performance, providing a different name seems like a reasonable option. On the opposite, it has the potential of breaking it. It is clear to me that class `error_code` means two quite incompatible things. One is "just status" -- success or failure, or something in between. The second one is "reason for failure" (failure implied). The former was intended in the initial design. But there are things that indicate the latter: name "error", or conversion to bool, which conventionally means "valid or not?", "interesting or not?", "populated or not?". Users do not get clear message whether they should treat it as "reason for failure" or "just status". Regards, &rzej;