Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk