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: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-01-22 11:22:19

It has just occurred to me that the name std::error_code is a misnomer.

What this structure actually represents is *result code* and a domain*.* It
has been correctly pointed out that sometimes result codes are not errors
(e.g. errno == EINTR during a select())

In hindsight perhaps it should have been called std::result_code(code,
std::system_call_domain()).

As mentioned, I like the outcome<> approach, but for use in things like
asio (networking TS), outcome would meed a polymorphic wrapper) since
user-defined IO services need not exclusively acquire their error codes
from the system_category().

On 22 January 2018 at 00:44, Rob Stewart via Boost <boost_at_[hidden]>
wrote:

> On January 19, 2018 1:02:10 PM EST, Robert Ramey via Boost <
> boost_at_[hidden]> wrote:
> > 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.)
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>