On Fri, Apr 5, 2019 at 7:55 PM Larry Evans via Boost
On 4/5/19 7:46 PM, Emil Dotchevski via Boost wrote:
On Thu, Apr 4, 2019 at 4:30 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
The problem with transitioning to an otherwise valid but unexpected state is that it may end up evaluating unintended code
This is why I made the analogy with std::vector. Let's say you always
put
exactly 10 elements in all your vectors, but then you assign one vector to another, and that fails, and now (unexpectedly?) you have an (otherwise valid) vector with fewer than 10 elements.
Such is life. This is how the basic guarantee works, you get an unspecified but valid state.
(Granted, continuing evaluation on a faulted variable is already a bug in itself, but you are making detection of that bug harder by not putting the value into an obviously-faulted state.)
I do not think that it is a bug to access an object that is in a valid state. In fact, the reason why the state is defined as valid is so that you can safely work with that object, even after a failure was reported.
I'm guessing "unexpected" could mean the std::vector could have some arbitrary number of elements all filled with random values. I don't see how you can do anything useful with that.
The values aren't random, they are guaranteed to be valid. From the point of view of the type system and what a vector is, it is illogical to complain that it has fewer than 10 elements. It is fine for vectors to have fewer than 10 elements. The way I formulated the example makes it feel like there is something wrong with that state, because we always put 10 elements in all vectors and now we find one with fewer than 10. But this has nothing to do with vector. To do this correctly, we need to write a wrapper type for vector that has a size-10 invariant, then define the appropriate safety guarantees for that type.