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 15:35:53

2018-01-16 15:59 GMT+01:00 Niall Douglas via Boost <boost_at_[hidden]>:

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