[boost] Re: Boost.Variant collaboration effort

From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-07-20 06:44:03

Having been inspired by the "boost::function<R(*)(A1,A2)>" discussion, I
thought we might borrow something to Boost.Variant:

Instead of supplying variant_cast<>/extract<> functions, variant.hpp can
supply overloaded versions of any_cast<>, which accept a variant value,
rather than a boost::any value. These functions will use some sort of
deprecation trickery (as described in the above-mentioned discussion), and
will provide the same functionality as variant_cast<>.

By doing so, boost::variant will have full source-code compatibility with
existing any-based code, with the additional benefit of promoting the use of
functor visitors, over the (clumsy) "if (any_cast<T>(&v))" constructs, in
future code. The down side of this idea is the coupling of variant semantics
to an any-related primitive, but I think this cost might be worth paid.

Thought?

-Itay

"Eric Friedman" <ebf_at_[hidden]> wrote in message
news:ahahja$l8k$1_at_main.gmane.org...
> 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
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>