On Mon, Jan 14, 2013 at 4:37 PM, Larry Evans <cppljevans@suddenlink.net>wrote:
[...]
Thus, there is no indication in the variant that anything has gone
wrong other than the fact that the variant's value has not changed from it's state before the assignment. This test for the exact same value seems to be an "additional complexity-of-use" which, according to:
http://www.boost.org/doc/libs/1_52_0/doc/html/variant/design.html#variant.de...
the never-empty guarantee was supposed to insulate the user from.
Wouldn't the "implicit" boost::blank default construction be a "less complexity-of-use" alternative? IOW, when an exception occurs during an assignment of two distinct types, the variant's type is changed to boost::blank even when that is not among the explicit bounded types. This would be a flag to the user that something unusual had happened and would easily be tested for with the which() function which would return some value (e.g. -2 or -999 or whatever) indicating that the value is "undefined".
An exception being thrown (well, propagated) is a fairly strong indication that something unusual has happened. Variant does not swallow the exception that caused the rollback. -- gpd