On Sun, Apr 14, 2019 at 4:48 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 15/04/2019 08:58, Emil Dotchevski wrote:
Yes, but the question was about the benefits of the never-empty guarantee. If the never-empty guarantee doesn't help with maintaining higher level invariants, then what benefit does it bring?
If the design allows for one more state, then that state must be
handled:
various functions in the program must check "is the object empty" and define behavior for that case. The benefit of the never-empty guarantee is that no checks are needed because the object may not be empty.
As I've said elsewhere, I don't see the difference between "is this empty" and "did this unexpectedly change type", except that the former is easier to detect (and hence better).
Let's say an error occurs, and a member variant's state now violates the invariants of the enclosing type. If there is a special empty state -- or if there isn't -- under the basic guarantee you'd catch the exception and do work to restore the invariants. There is no difference in the recovery steps, and once they are complete, there is nothing to detect, the object is as valid as any other. The benefits of the never-empty guarantee are elsewhere, not during error handling, in that the presence of the empty state requires the program to deal with it.