On 01/21/13 17:51, Hartmut Kaiser wrote:
On 1/22/13 3:57 AM, Antony Polukhin wrote:
I've got some nice idea from discussion: nullable variant. If many people use or want to use a variant with a type, that represents empty state, we can create a separate nullable variant class. I think that nullable variant can be implemented more efficient that the current variant. For example we can simplify copy/move constructors and assignment operators, guarantee fast noexcept default construction, simplify metaprogamming and reduce compilation times. Maybe someone want to implement it?
I like it! If you implement it, I'll be your first user :-) I don't really care much about this "never empty" guarantee and I think it's not really worth the trouble.
I'd prefer to have a nullable variant as well. If not that, then I would like to support II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations.
OR have get<T> return recursive_wrapper<T> and then the user would have to check whether it's nulled. This avoids the need for BOOST_ASSERT; however it does violate the contract: This "never-empty" property insulates the user from the possibility of undefined variant content and the significant additional complexity-of-use attendant with such a possibility. mentioned here: http://www.boost.org/doc/libs/1_52_0/doc/html/variant/design.html#variant.de... however, setting operator.p_ to NULL does the same but makes it harder for the user to detect since the user would have to use a try/catch to test it, IIUC. -regards, Larry