On Thu, Oct 28, 2010 at 1:37 PM, David Abrahams <dave@boostpro.com> wrote:
One more question: if you are doing tag dispatching internally anyhow, might it make sense to have the dispatcher function not SFINAE'd at the top level, but instead automatically static assert the concept check in the function body?
Yes. That's sort of the motivating case for (break if) and should be enough to do just that. Taking this a bit further, perhaps in the direction you are alluding to, a more descriptive approach for situations with concept overloads might be to make the base concept requirements for parameters able to be specified as a part of the "switch" parameter. By that I mean something such as the following for the initial "dispatching" function: BOOST_AUTO_FUNCTION ( (template< class It >) , (foo)( (switch forward_iterator)(It)(iterator) ) , (explicit It) ) This would do something like what you describe -- it would static_assert in the body with a concise message telling the user exactly what is wrong and it more directly associates the parameter with its base concept requirements prior to branching off to appropriate implementations. Concepts should also be able to be tied directly to parameter types on templates that aren't branching off. For that, the syntax could be similar only instead of the keyword "switch" I could use "for" or "catch" or even "if" again, or I could make it just automatically detected if a parameter in the parameter list is a 3-element Boost.Preprocessor sequence (well, the variadic equivalent), in which case it just assumes that the first element of the sequence is the concept if and only if "switch" isn't the first word to appear in the head element. This macro is really becoming a beast, but in a good way. It's scary to think that I'm running out of good C++ keywords to use and am already considering re-using some within the macro itself when in different contexts. -- -Matt Calabrese