Boost logo

Boost :

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-02 22:11:04

>> The discussions are interesting, but when they evolve into communal design
>> from a simple review things get ... complicated. Maybe if we kept reviews
>> more focused on thumbs up/down and criticism and support rather than
>> "design" they might be less of a death march and we might encourage more
>> people to participate in reviews.
> In this spirit, I have got a question to Niall, or whoever who used the
> library in their real projects: did the use cases required to change the
> state of a once constructed `outcome`?

I gave many examples throughout the review of changing the state of
existing outcomes. Indeed, almost every AFIO object init function
implementation does so, we construct an empty or valued result<T> on the
stack and fill it in over time as part of the "two phase construction"
used throughout AFIO.

Also, in KernelTest, there is some constexpr code which statically
constructs a std::array<outcome<T>, N> at compile time exactly matching
the number of parameter permutations which will be run. After the test
has finished, empty outcome<T> means test was skipped or death test
failed, valued means test passed, errored means test errored, excepted
means test threw an exception.

So assignment of Outcomes, well I use it frequently. I've also passed in
outcomes by lvalue ref to a set of filtering callbacks, and each
callback may or may not change their state as part of their execution.


ned Productions Limited Consulting

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