
On February 5, 2018 3:43:49 AM EST, Andrzej Krzemienski via Boost
2018-02-03 23:32 GMT+01:00 Rob Stewart via Boost
: That result
is declared with [[nodiscard]] can be helpful. It means the return value of a function returning a result cannot be ignored. Unfortunately, the compiler doesn't require that the programmer do anything with the result except save it. (A warning might alert the programmer to do something with such a variable, but there's no enforcement.) Let me expand on this a bit. I have the following program where I save the result, but not inspect it:
``` #include "outcome.hpp" namespace out = OUTCOME_V2_NAMESPACE;
out::result<void> fun() { return out::success(); }
int main() { auto r = fun(); } ```
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
When I compile with GCC, I do not get this warning. But in my work, w compile programs with GCC, but still use clang for the static analysis pass, and nonetheless this bug would be detected.
IOW, one must use certain tools and options to get the protection. I think the library could, at least, assert in debug builds when a result or outcome is not inspected.
Of course, you could still overcome all the safety precautions and trigger an UB:
``` #include "outcome.hpp" namespace out = OUTCOME_V2_NAMESPACE;
out::result<void> fun() { return out::success(); }
int main() { auto r = fun(); (void)r; } ```
But I would not expect protection from such conscious attempts of overcoming safety measures.
I wouldn't expect protection then either.
The same is not documented for outcome, however. Thus, when using outcome, because one might need to convey an exception to the caller, there is no compiler help to ensure the programmer doesn't ignore the return value.
When I test the following program, it does tell me that I am not inspecting the returned outcome:
``` #include "outcome.hpp" namespace out = OUTCOME_V2_NAMESPACE;
out::outcome<int> fun() { return out::success(1); }
int main() { fun(); } ```
So, you probably mean something else than I think. Could you illustrate your concerns with an example?
I'm glad to see that, but note that I wrote that outcome was not documented as having that behavior. -- Rob (Sent from my portable computation device.)