Eric Friedman wrote:
As for operator!= (and operator<=, etc.), while I do think it may be useful, it raises the question of what requirements variant imposes on its bounded types. Specifically, adding support for these operators is not so straightforward as saying operator!= is simply !(*this == rhs). The idea of operator== and operator< is that if the current bounded type is the same in both variant instances, then operator overload _for that type_ will be invoked. To support this same behavior for the other operators would require adding to the bounded type requirements. See <http://boost.org/doc/html/variant/reference.html#variant.concepts> for a refresher on variant's approach to concepts. Maybe this is an overly-pedantic response on my part, though.
I think it *is* as straightforward as saying operator!= is simply !(*this == rhs). There is no other way that makes sense. Operators >, <=, >=, on the other hand, are completely different. I think there is no natural ordering of variant objects, so not supporting them is logical. Operator < is an exception because it's used for ordered conrainers. IOW, I completely agree with your decision to supply operator < and not supplying operators >, <=, >=.
The reason (or at least one of them) that apply_visitor accepts visitors by reference and not by value is that I had intended to introduce a dynamic_visitor counterpart to static_visitor in a more general Boost.Visitor library. Passing by value would interact poorly with polymorphic dynamic visitors due to slicing. If you are interested, I believe Boost.Visitor is probably still sitting around in the Boost Sandbox CVS on Sourceforge.
Then maybe different names should be used for dynamic_visitors, for example apply_dyn_visitor(). We need to consider whether the need for dynamic_visitors is large enough in order to justify the negative impact on the static_visitor's interface. Have you found there is great need for dynamic visitors? I have to admit that I've never needed them... Not to mention that the whole standard library is based on static functors passed by value...
Variant already supports reference types, at least on modern compilers. However, references are not assignable, and so as noted in the concepts documentation for variant, this implies that the resultant variant is not assignable. To address your comment about boost::optional, then, variant does not allow rebinding of references.
No problems here. I just want to express my opinion that the decision regarding reference support should apply both to Optional and to Variant.
I'll have to more carefully look at your proposals for additional get functions to see whether I am convinced of their utility.
I'd appreciate that very much. Thanks, Yuval