[boost] Boost.Variant collaboration effort

From: Eric Friedman (ebf_at_[hidden])
Date: 2002-07-19 21:23:47

Eric Friedman and Itay Maman have decided to collaborate on the development
of a single variant library design and implementation rather than to offer
two competing libraries. This decision was made upon the realization that
the two libraries were continually borrowing both inspiration and
implementation techniques from each other, ever-blurring the lines between
the work of the two authors.

Eric and Itay have not yet developed a single implementation or even come to
final decisions on the library's design; discussion is under way between the
authors at this time.

Topics currently under discussion include:

(1) Variant-to-variant conversion.

"Strict" conversion requires each of the source variant's bounded types to
be unambiguously convertible to one of the destination variant's bounded
types; "Non-strict" requires only the source variant's runtime value to be
convertible to one of the destination variant's bounded types, throwing an
exception if the conversion does not exist or is ambiguous.

Which should be the default conversion method (strict being safer,
non-strict more useful), and should both methods be supplied?

(2) Default construction of variant types/"emptiness" of variant values.

Should variant default construct the first type specified in its bounds or
should it initialize to an 'empty' state (like boost::any)?

The former is arbitrary (though arbitrariness may be documented). But the
latter, while elegant, may introduce greater complexity in user code (i.e.,
can a variant be "emptied" once it is non-empty? under what conditions must
the user check against variant::empty()? and so on).

Currently variant::empty() is provided only for type signature compatilibity
with boost::any and always returns a true value. Is the concept of an empty
variant an important or useful one?

(3) Algorithmic complexity of variant visitation.

O(1) is possible but introduces need for some thread-safety primitives and
(minimal) space overhead; O(N) is achievable via cascading if statements.

On one hand it is unlikely N (i.e. the number of bounded types) will grow
large, and so the question seems moot; on the other hand, there may be uses
for variant that have not yet been imagined -- and which may leverage N that
is large.

What should be required of a conforming variant implementation?

(4) Non-member variant functionality, e.g., type_switch, extract<T>,
try_convert (for non-strict variant-to-variant conversion), etc.

Should these facilities be treated as separate libraries from Boost.Variant,
as they are not variant-specific? How would such an approach be handled if
variant were accepted into Boost?

---
Feedback is welcome and desired.
Thanks,
Eric Friedman and Itay Maman