I can confirm the first part: “P subsumes Q”, as per the definition of “subsumes” in the C++ Standard (included in this post). I am not prepared to talk about symbol ⊆, as I do not know what it means to you; nor is it defined in the C++ Standard.

]]>Consider your Tool::operator=(Tool&&) from above: Why don’t you simply throw an exception on failure instead of relying on old C-style return semantics? I mean, throwing an exception is supposed to be the way to signal a failure in C++ (at least in the context of the noexcept specifier), i.e., nofail noexcept.

Arguing that specifying noexcept for your Tool::operator=(Tool&&) is semantically wrong (which it clearly is in your case) when you escape from that function by non-exceptional means on failure, is like manipulating a class via a pointer to its memory region and then complaining that the class’ invariant is broken.

The point is: Use noexcept if and only if you do return all failures from a function via exceptions and your particular function does not throw (i.e., has no failures).

]]>Since this was written, C++20 seems to have introduced a new keyword, `constinit` to do exactly this: Require that at variable is constant-initialized, without also making it `const` like `constexpr` does. See https://en.cppreference.com/w/cpp/language/constinit

]]>You can be sure when the library author provides a strict mathematical proof that his algorithm works under the given requirements. For example, the Euclidean algorithm works for all Euclidean domains (and Euclidean domain is essentially a semantic concept).

For the library author, the iterative process does not end after a certain “number of iterations”; you have to iterate until you find a mathematical proof.

]]>