Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?

Subject: Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-01-19 17:16:04

On Sat, Jan 13, 2018 at 8:05 PM, Christopher Kohlhoff via Boost
<boost_at_[hidden]> wrote:
> The error_code class itself deliberately does *not* imbue zero values with
> the meaning 'success' and non-zero values with the meaning 'failure'. An
> error_code simply represents an integer and a category, where the category
> identifies the source of a particular integer value. The specification of the
> error_code class carefully avoids making any judgement as to whether a
> particular value represents success or failure. The construct:
>
>   if (ec) ...
>
> does not, in and of itself, mean 'if an error ...'. Instead, operator bool is
> specified to behave as the ints do, and the above construct should simply
> be read as 'if non-zero ...'.

That might have been the original design intention, but that ship sailed a long
time ago. It is well established that users are habituated to think of the bool
conversion as meaning success or failure.

> When defining your own API you are free to define your own notion of success
> or failure. One way would be to define your own error_condition for this
> (an intended use case for error_condition), but you may also use some other
> mechanism entirely (indicate failure via exception, return value, etc.). You
> might like to consider this approach for your own API that wraps NT kernel calls.

Nobody wants to write

    if(ec == my_condition::success)

When then can instead write

    if(! ec)

Even in your own code you write `if(! ec)`:

<https://github.com/boostorg/asio/blob/6814d260d02300a97521c1a93d02e30877fb8ff5/example/cpp11/http/server/connection.cpp#L44>

Whether it was intended or not, established practice is to treat the bool
conversion of error_code as false==success and true==failure.

I have long felt that the documentation for <error_code> and <error_condition>
is terribly inadequate which probably accounts for the pervasive misconceptions.
The standard is completely unhelpful in offering guidance on its use, and all of
the usual websites (cppreference.com or the boost docs for example) are
similarly unhelpful. Chris' blog posts on error_code were instructive but
incomplete. Andrezj's blog posts did the best job of providing tutorial-like
guidance but of course I read them too late.

People are still trying to figure out how to use error_code and having trouble
because it isn't well explained. Ideas like "if(! ec)" should not be used to
check for success do nothing to improve this situation.

Thanks