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