Boost logo

Boost :

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-02-06 09:25:07


2018-02-06 10:15 GMT+01:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> 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;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk