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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-01-16 22:16:24

2018-01-16 19:58 GMT+01:00 Andrey Semashev via Boost <boost_at_[hidden]>
:

> 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;