Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at