Re: [boost] [variant] wish list

From: Eric Friedman (ebf_at_[hidden])
Date: 2006-06-08 01:31:28

Yuval,

Yuval Ronen wrote:
> 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.

I of course agree with you that this definition of operator!= makes 
sense, but I am reluctant because this is not how C++ works: the 
language allows entirely separate definitions of operator== and 
operator!=. It would seem unfortunate I think if variant called 
operator==(T,T) but never operator!=(T,T)...

> 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 >, <=, >=.

Now how is that operator!= as !(lhs == rhs) makes sense, but operator<= 
as (lhs < rhs || lhs == rhs) is completely different?

>>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...

I think my opinion here is that a visitor is fundamentally different 
from a functor. Functors model function types; they may be implemented 
with a template, but logically they have a single signature. By 
contrast, a visitor is a set of functions with different signatures used 
to handle a set of different cases.

Also, looking back to your original email, you mentioned a desire to 
pass temporary visitor objects. I believe that is supported with the 
current implementation. The following compiles just fine under gcc 3.4:

   #include "boost/variant.hpp"

   class TestVisitor : public boost::static_visitor<>
   {
   public:

     template <typename T>
     void operator()(const T&) const
     { /*...*/ }

   };

   int main()
   {
     boost::variant<int, double> var;
     apply_visitor(TestVisitor(), var);
   }

>>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.

So you think Optional should change or Variant should change?

Eric