Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-02-06 09:15:14
>> When I compile with clang, with -Wall -Wextra -Werror, I get an error
>> saying, "unused variable 'r'". See online examle:
> IOW, one must use certain tools and options to get the protection.
If you're not using clang-tidy in your project, then you ought to start.
I've managed to raise it on an ancient VS2008 codebase. It surprisingly
> I think the library could, at least, assert in debug builds when a result or outcome is not inspected.
What does "not inspected" mean?
In C and C++, historically when the programmer wishes to signal that
they are intentionally throwing away a result, they write:
extern result<int> foo();
// I don't care if this succeeds or fails
So okay, perhaps people should do that. But this is something people
result<int> r = foo();
x = r.value();
So now we need to make the explicit boolean operator become non-const in
order to get it to set an internal flag so that the destructor can trip
an assert on uninspected destruction.
Now, I don't mind doing this, indeed I've left a free status bit for
this sort of thing in the future. But are:
- Non-const boolean operator
- Non-const .has_value(), .has_error() etc
- Non-const .value(), .error() etc observers
... a price worth paying for asserting an uninspected result, and this
includes breaking the cast-to-void idiom?
One could of course const cast off any const-ness, and flip the
inspected bit on any form of inspection. But I personally think there is
a much better way that what you propose Rob, and that's to use the
construction hooks to log the construction of result/outcome in debug mode.
This is what I do in my own code. See
This lets one detect, much more easily and without breaking behaviour
semantics, unintentionally uninspected outcome/result.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk