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
>> 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
>> 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.
> Heck, Boost example code advertises this is the correct way to use
Maybe so, but that doesn't convince me that it's a good idea.