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: Rob Stewart (rstewart_at_[hidden])
Date: 2018-01-21 23:44:55

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.)