Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-24 01:17:15

On 24/05/2017 03:19, Niall Douglas wrote:
> I never found a use for that particular variety in my own code, but I
> find the semantics very attractive. They impose rigour. I just wish I
> could make the statically obvious failure to collect state a compile
> time instead of runtime error.

I mentioned earlier that if the entire result<T> or outcome<T> class 
were declared [[nodiscard]] then this should have the effect of the 
compiler issuing warnings and/or errors if one is returned from a method 
and the caller fails to do *something* with it.

(This came up in the context of you wondering whether some individual 
methods such as value() should be [[nodiscard]], but I don't think 
that's the correct approach.)

In particular this should handily catch the case where a void-return 
method is changed to an outcome-return method in a later version of a 
library (or app-internal method), which is probably the 
second-most-common case of ignoring error returns (the most common of 
course being lazy programmers).

Sadly this is C++17-only.  Though I dimly recall another technique 
involving rvalue methods that only requires C++11 being used in another 
proposed library.  It's possible that I am recalling incorrectly and 
this was also runtime-only validation, however.