On Tue, Jan 8, 2013 at 8:09 PM, Peter Dimov <lists@pdimov.com> wrote:
Paul Smith wrote:
Sure. My point was that "destructible and assignable" are not always enough as far as the library goes.
Yes, I agree. To expand on that, the requirements defined by the standard library such as CopyConstructible, LessThanComparable, and so on, do not have preconditions. So if a movable type claims to conform to these requirements, it can't impose a precondition that the operations only work on values that haven't been moved from. And the same holds for requirements defined by libraries other than the standard library.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
That's exactly my point. If you were doing something like this (i.e. nullifying rec_wrap) in your own code, I wouldn't be all that concerned because you should know the requirements from your own types. But variant is a generic library, which is used by different people that have different requirements. Once we decide that moved-from recursive_variants need to be less-than comparable for the STL's sake, we essentially admit that the moved-from state *is* visible. And why stop here? Why just guarantee comparability? Different users might have other equally legitimate requirements just as well. The only way to make everyone happy is to guarantee that a moved-from recursive variant is a valid variant. -- Paul Smith