[boost] Switch library review - summary of discussion so far

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-01-11 20:18:40

I will try to summarize the discussions happening so far on the Switch
library under review - maybe this will be helpful to those considering
joining the discussion and submitting a review.

* Documentation

All reviewers have noted that the documentation could be improved -
e.g., additional examples, performance stats, as well as more
explanation of the types involved and how they are used.

* Return type

Tobias Schwinger suggested that the return type should be specified
explicitly in the switch_ call, rather than inferring it from the
function object, and this is now a part of the recent designs being
discussed.  Joel de Guzman also suggested that if a version of switch_
should infer the return type, that return type should be a
Boost.Variant of the types returned by each of the cases.

* Default default behavior

If the default behavior is left unspecified, switch_ should invoke the
default constructor of the return type in the default case, rather
than throwing an exception.  This was suggested by Tobias Schwinger
after the issue was raised by Dan Marsden.  Alexander Nasonov has also
indicated that a throwing default case can cause inefficiency, even
when it is guaranteed not to be invoked.

* Fall-through

Alexander Nasonov pointed out the lack of fall-through capability in
the submitted implementation.  Fall-through has been incorporated into
the recent designs being discussed.

* Allowing void-returning function objects for the default case with a
non-void returning switch

Tobias Schwinger mentioned the possibility of allowing default case
function objects of void return type even when the switch return type
is non-void, as long as the function object call does not return.
This would be useful, for example, if the function object is
guaranteed to throw.  There is still some discussion on whether
determining if the return type is void can be done efficiently.

* Design

There has been a lengthy discussion on the underlying design of the
library, what it should offer, and whether the name of the library is
appropriate.  There are two types of designs that have been put
forward as being appropriate and/or necessary for a Boost.Switch
library.  On one hand, there is the submitted design (labeled "A" in
recent postings), which takes the switch cases in an MPL sequence and
a single function object containing implementations of all cases.
Joel de Guzman has proposed another design (labeled "B"), in which the
switch cases are specified separately and allow a different function
to be used for each case.  Design "A" is better suited for situations
in which the number of cases is determined by a compile time constant,
while "B" is more appropriate for many use cases, and provides more
flexibility and a more familiar syntax.  It seems that a consensus has
been reached that this library could offer either both interfaces in
different layers, or an interface that can be used in different ways
for different uses (based on a common concept capturing case
sequences).

(Apologies if I have missed or misinterpreted something)

More reviews/votes would be extremely welcome!

Regards,

Stjepan