Hi Peter, Thank you for writing and sharing this implementation of variant. I am sorry if I am bringing back an issue that has been already discussed and solved before, but I do not understand the rationale behind doing compromises in order to provide the never-empty guarantee. The short rationale provided in Boost.Variant library: https://www.boost.org/doc/libs/1_69_0/doc/html/variant/design.html#variant.d... was provided before we got C++11 the moved-from state in the language. Today, it should come as no surprise to programmers that a type might be in a "moved from" state where only a limited interface of an object can be used. The guarantee provided by variant's assignment is not a strong exception safety guarantee: it is possible that my variant has value A, I want to assign value B, and (due to an exception) I end up with value C. If this happens, the only thing I can reasonably do is to either abandon whatever I was doing or reset the variant to the state that I need. So the guarantee that it is not left empty does not seem to be of much use. But the cost to be paid is noticeable. I think that this question should be addressed in the documentation. Regards, Andrzej