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.