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

Subject: Re: [boost] Boost.Outcome review - First questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 15:31:45

>> > Back at the beginning when designing Outcome, one of my design ideas
>> was > a variety which called std::terminate on destruction if an error
>> had > never been retrieved. So, the idea behind this family of
>> Outcomes was > that they were "single shot", .error() and .value()
>> could be called > exactly once after which the outcome became empty.
>> On destruction, if an > error had never been retrieved, it was fatal
>> exit time.
> 
> I wouldn't go as far as calling terminate(), but one could log.

I'd make what happens user definable of course, but the default
implementation would be std::terminate. After all, these be rigorous
Outcomes, failure to collect state is a logic error - it equals "your
code is wrong".

> But for
> this to work, the outcome must be noncopyable (move-only). Otherwise if
> you make a few copies, none of it could know whether you inspected the
> error of some of the other copies or not.

I had been thinking of copy constructor disabled, but there would be a
clone() member function.

> This doesn't require an empty state though, just a bit that is set (or
> maybe cleared) when error() is called.

I think the source of our disagreement is over publicly exposing the
empty state. You appear to be happy if it's an internal only thing, but
not available to end users. I take the view that if you're implementing
the empty state anyway, might as well open it up for public use.

Can you give a reason why public availability of an empty state with
well defined semantics and behaviours is a bad idea? Does it naturally
lead to incorrect code or something?

Niall

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