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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-01-16 18:22:12

On 1/16/18 10:06 AM, Nevin Liber via Boost wrote:

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

I don't think it's just for the sake of churn.  I think it's to improve 
program correctness by replacing ambiguous and opaque implicit behavior 
with unambiguous explicit behavior which is obviously correct on it's 
face without having to go look it in some documentation or source code 
somewhere else.
> 
> 
>> c) and likely in some cases smoke out some errors
> 
> 
> Please provide some evidence to back up this assertion.

LOL - I can't "prove" that its going to smoke out some error.  But 
that's not the point.  One can't "prove" that the current usage is 
correct by looking at it. My experience is that something which is not 
obviously correct eventually comes to be seen as incorrect.

> If the premise is
> that filesystem, asio and dll and the dominant use cases, 

This is not a premise for me.

>I'm not seeing any errors.  

Of course you're not.  The current API hides any which might be there. 
That's exactly my complaint.  You cannot prove there are no errors in 
the usage simply by observation.

> And if that isn't the premise, then what are the dominant use
> cases for error_code?

I see error_code as a way to reconcile varying lists of error codes in a 
systematic way which will avoid confusion which often leads to subtle, 
hard to find, bugs.  Certainly I see it as much more general then three 
boost libraries.

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

The fact that something is in wide usage is not enough to convince me 
that it's a good idea.

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

see above

> Heck, Boost example code advertises this is the correct way to use
> error_code.

Maybe so, but that doesn't convince me that it's a good idea.

Robert Ramey