> The easy way out is to say that invariants are “observable” properties and nothing can observe the broken invariant in the middle of the method call. Unless

> The easy way out is to say that invariants are “observable” properties and nothing can observe the broken invariant in the middle of the method call. Unless you are invoking user-defined functions in the middle that can observe it. This can be tricky for example in C++. The user-defined functions can be explicit callback arguments, but as simple as copy/move-constructors or conversion operators can trip you up. For C++ standard library containers the public member functions are not guaranteed to be reentrant for example (the wording for this is not great though). https://godbolt.org/z/xKMoxrr3E https://godbolt.org/z/xKMoxrr3E This might be a contrived example. But I actually had something like this happen when I wrote a generic memoization class that used an unordered map under the hood, and then I tried to memoize a recursive function. It ended up calling the same map's `try_emplace` function recursively, which blew up spectacularly with abseil's implementation of unordered_map.