[boost] [variant] late "review"

From: David Abrahams (dave_at_[hidden])
Date: 2006-11-04 18:03:24

I'm just looking through the variant library docs in detail and had
the following commments:

* http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/variant/tutorial.html 
  shows static_visitor being used with no arguments and yet
  http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost/static_visitor.html
  doesn't indicate any default for the first parameter.  Also, once
  you start using an argument in the tutorial, it comes with no
  explanation, which is confusing.

* It's not obvious why we're deriving anything from static_visitor.
  It seems as though it shouldn't be necessary and that it might not
  be simplifying anything.

* I find the dual nature of apply_visitor confusing.  With two arguments it
  is an imperative command: "apply this visitor."  With one argument
  it is a wrapper generator or something like that: "make this visitor
  into a function object that operates on variant<T0,...TN> instead
  of on T0, ... TN directly."  [Actually, I'm not sure the latter
  description is accurate and it wouldn't hurt to have it spelled out
  in the docs.]  I think it would be better to use two names rather
  than overloading one name in these two very different ways.

* I have a very clear mental model for what a non-recursive variant is
  doing, which gives me a clear of its costs and of where I'd use it:
  it's like a supercharged union.  From reading your docs it's very
  hard to form the same kind of mental model for a recursive variant.
  It would help to be explicit about what the library generates for
  you in the recursive case.

* The make_recursive_variant example is vague.  It should describe
  what the result is equivalent to.  I presume it's something like:

       variant<int, ...

  ...uhh, interesting: I don't think you can express that example in
  terms of just variant and recursive_wrapper.  However, the text
  implies that make_recursive_variant is just a less-flexible way to
  achieve a subset of the same goals.

* binary visitation:

         "Notably this feature requires that binary visitors are
         incompatible with the visitor objects discussed in the
         tutorial above, as they must operate on two arguments."

  I don't get it.  I can make an object whose function call operator
  overload set can operate on both 1 and 2 arguments.

* It seems like visitor_ptr is a very specialized name for something
  very general-purpose.  Doesn't bind(fp) (or some other boost
  construct) do the same thing?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com