Re: [boost] [outcome] Exception safety guarantees

Subject: Re: [boost] [outcome] Exception safety guarantees
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 23:09:11

2017-05-28 0:55 GMT+02:00 Emil Dotchevski via Boost <boost_at_[hidden]>:

> On Sat, May 27, 2017 at 3:15 PM, Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> > I suppose either interpretation is correct, depending on how strong you
> wan
> > the invariant to be.
> >
>
> Nope, this is a matter of definition -- basic exception safety is _defined_
> to mean something. Other interpretations are incorrect, or rather, disagree
> with the definition.
>
>
> > But tell me this. Consider the example with class Man above:
> >
> > ```
> > struct Man { std::string fist_name, last_name; };
> > Man m1 = {"April", "Jones"};
> > Man m2 = {"Theresa", "May"};
> >
> > try {
> >   m2 = m1; // suppose it throws
> > }
> > catch(...)  {
> > }
> > ```
> >
> > Object m2 after recovering from stack unwinding may be in the state
> > {"April", "May"}, which is a "valid state". Would you call it a valid
> > state? It is "valid" in the sense that reading values from its members
> does
> > not cause UB, but its "high-level invariant" (that m1 should refer to an
> > existing person) is broken. It conveys no useful information.
>
>
> This is not about usefulness but validity. When we say that
> vector::push_back has basic exception safety guarantee (in general, it is
> strong in case no reallocation occurs), it doesn't mean that you're going
> to find anything "useful" in the vector in case of failure. It only means
> that any objects that remain in the vector are in valid state, and the
> vector itself is in a valid state.
>

Yes, it is "valid, and the elements are "valid"; and what do you do next?
Because the only ways to proceed I see is to leave the scope and have the
vector destroyed. Or clear it, ao assign a different, meaningful vector.

>
> What does it mean for an object to be in valid state? This means that its
> invariants are in place. In C++ this is formally supported by the semantics
> of constructors: a constructor succeeds in establishing the invariants of
> the type or it does not return.

Yes, I understand that; and in the context of this thread for the purpose
of describing valueless_by_exception state, I claim that the invariant for
expected<T, E> is:

 `this->valueless_by_exception() || /* other parts of invariant*/`

That is, I artificially widen the invariant. Peter's claim (if I understand
correctly) is that by this artificial invariant widening I make the
semantics fuzzy beyond reason. But my claim is quite the opposite. Any more
guarantee is never needed. I cannot see where/why we disagree.

> Note that there is no provision to report a
> failure (to establish the invariants) except by throwing. This is not an
> omission but a deliberate design choice.
>

Interesting. I do not know what you mean here. Maybe, "there is no other
way to report such failure except to throw an exception"? If so, I agree,
but how does this relate to the discussed topic?

Regards,
&rzej;