Re: [boost] Reforming Boost.System and <system_error> round 2

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Nevin Liber (nevin_at_[hidden])
Date: 2018-01-16 18:06:14

On Tue, Jan 16, 2018 at 11:44 AM, Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> On 1/16/18 8:56 AM, Nevin Liber via Boost wrote:
>
>> On Tue, Jan 16, 2018 at 9:47 AM, Andrzej Krzemienski via Boost <
>> boost_at_[hidden]> wrote:
>>
>> This attempts to make everyone happy.
>>>
>>
>>
>> Then the attempt to *annotate the conditional conversion to bool
>> deprecated*
>>   fails.
>>
>> While it makes the people who love verbosity happy, it does so at a cost
>> of
>> breaking perfectly correct, well-tested code, and I suspect a large amount
>> of code at that.
>>
>
> a) True - it would break code by invoking a compile time error
> b) which would be trivial to fix
>

For people who don't have to pay.  Churn for the sake of churn is costly
for those who have to pay for testing, external software verification, etc.

> c) and likely in some cases smoke out some errors

Please provide some evidence to back up this assertion.  If the premise is
that filesystem, asio and dll and the dominant use cases, I'm not seeing
any errors.  And if that isn't the premise, then what are the dominant use
cases for error_code?

> Heck, it even breaks Boost code.  I would guess that
>
>> filesystem, asio and dll are some of the biggest users of error_code, and
>> not only do users of those libraries regularly use "if (ec)", those
>> libraries themselves internally use the same construct.
>>
>
> d) So we would find some new bugs in Boost as well.  Sounds like a feature
> to me.
>

My spot-checking of this idiom in Boost finds no bugs.  Please provide
evidence of a bug in Boost caused by this.

Heck, Boost example code advertises this is the correct way to use
error_code.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]