Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Rob Stewart (rstewart_at_[hidden])
Date: 2018-02-06 00:00:58

On February 5, 2018 3:43:49 AM EST, Andrzej Krzemienski via Boost <boost_at_[hidden]> wrote:
> 2018-02-03 23:32 GMT+01:00 Rob Stewart via Boost
> <boost_at_[hidden]>:
> 
> > That result<T,EC> 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.)