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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-03-02 06:34:53

On Fri, Mar 1, 2019 at 9:37 PM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:
> My hypothesis is that reading valid-but-unspecified can only happen in a
> buggy program in an unintended path.

Running out of memory, or out of some other resource, does not indicate a
bug. In response, under the basic exception guarantee, you may get a state
which I'm saying shouldn't be merely "destructable" but also valid. For
example, if this was a vector<T>, it shouldn't explode if you call .size(),
or if you iterate over whatever elements it ended up with.

> And that making design compromises to
> address this path is not necessarily the best approach to take.

Consider that if you choose to allow, after an error, to have objects left
in such a state that they may explode if you attempt to do anything but
destroy them, there may not be any way to detect that state. Assuming you
don't want your program to crash, your only choice may be to support this
as a "valid" state anyway, if not in the object itself, then through some
external indicator.

It's just better if all elephants you encounter are grey, even if they show
up where you don't expect them. :)