Re: [boost] [outcome] expected, etc. why are these assignable

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/