Subject: Re: [boost] Boost.Outcome review - First questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-24 16:29:02
Le 24/05/2017 à 17:31, Niall Douglas via Boost a écrit :
>>>> 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".
I don't think we should manage this with complex implementation. We
should use attributes and static analysis.
>> 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.
You see. Managing this kind of possible issues make the implementation
more complex than necessary.
E.g. Would you remove new because the user could not store it in a
variable and delete it later on?
>> 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?
Because it makes the user code more complex. This is the task of static
We have a lot of examples maintaining publicly this empty state because
the cost of ensuring this empty (partial state) is not expensive. We
have it with unique_ptr, exception_ptr.
However, how many lines of code have you seen that checks for whether
exception_ptr contains an exception or not?
Anyway, I have not understood yet when we need this empty state on the
implementation and les yet when does the user needs it. I'll persevere.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk