Re: [boost] [variant2] Need rationale for never-empty guarantee

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-03-02 05:44:12

sob., 2 mar 2019 o 01:03 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> On Fri, Mar 1, 2019 at 2:18 PM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
> > variant2 also only provides *basic* exception safety guarantee: you can
> be
> > assigning a variant containing type B to a variant containing type A and
> > end up with variant containing type C. Here's an example:
> > https://wandbox.org/permlink/AObFiUKgeXIEiXQa
> >
> > My point is, you can only observe the valueless state in variant if you
> > work with objects that threw from a basic-guarantee operation. But if you
> > do this, you already have mess in your program regardless if you are
> using
> > variants or not.
>
> This is true only if we define "mess" to mean "an unspecified but valid
> state".
>

I meant "mess" in the sense of stopping stack unwinding in arbitrary, not
well planned, places, not paying attention which objects go out of scope
and which are preserved.

I would appreciate someone giving me example of where:
1. stack unwinding is stopped in places that leave objects in a "valid but
unspecified state" and
2. this state is actually read instead of being destroyed (or overwritten)
and
3. this makes sense (it is not immediately classified as programmer doing
something wrong)

Regards,
Andrzej