RE: [boost] Boost.Variant collaboration effort

From: Keith Burton (kb_at_[hidden])
Date: 2002-07-20 02:56:37

I offer my opinions as someone waiting to use the result

(1) it must be possible for a developer to force the situation where
strict conversion is the only option
Therefore non-strict conversion should only be available via an explicit
mechanism

(2) the important difference between variant and any is that variant
always contains a valid value of one of it's types
Therefore initialising to the default value of the first type is the
choice to go for.
Incidentally I would not provide variant::empty() 

(3) why is there any need for thread-safety primitives ?
All my experience tells me that putting 'thread safety' into classes at
this level just generates an illusion of safety with an unnecessary
overhead for every use.

Keith Burton

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Friedman
Sent: 20 July 2002 03:24
To: boost_at_[hidden]
Subject: [boost] Boost.Variant collaboration effort

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