On Fri, Mar 1, 2019 at 9:37 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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. :)