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: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-01-20 11:10:53

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Vinnie Falco via Boost
> Sent: 19 January 2018 17:16
> To: boost_at_[hidden]
> Cc: Vinnie Falco
> Subject: Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
> 
> 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.
> 
> Nobody wants to write
> 
>     if(ec == my_condition::success)
> 
> When then can instead write
> 
>     if(! ec)

But who wants to *read*

   if(! ec)

when it is 'ambuguous'?  (and the ! can easily be missed at a glance.)

Boost prefers clarity to curtness.

if(! ec) is a bad habit - just stop it! Now!

Paul

PS but don't mess with existing code that works OK.