2018-02-06 10:15 GMT+01:00 Niall Douglas via Boost
When I compile with clang, with -Wall -Wextra -Werror, I get an error saying, "unused variable 'r'". See online examle: https://wandbox.org/permlink/WE7dK6r5XCIxJ83f
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 works.
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 (void) foo(); ```
So okay, perhaps people should do that. But this is something people definitely do:
``` result<int> r = foo(); if(r) { 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.
What you could do is to offer to compile your library in a special debugging mode. And only in this mode would you offer the additional run-time checks. In this mode you could just add a mutable member to track whether the error has been read or not. Regards, &rzej;