Hi John,
The main disadvantage I've noticed at present, is that the mangled names of the policy class - and therefore all the special functions etc - are *very* long. This has an impact on error messages: in particular we currently use BOOST_CURRENT_FUNCTION to get a nice formatted name of a function that's about to throw, but with function names a couple of pages long I don't think that will be possible with this interface any more :-(
What about moving the policy stuff into a traits class instead, combined with a policy id? namespace boost { namespace math { template <size_t ID> struct policy_traits { // default policy static const bool check_domain = true; static const size_t internal_precision = 16; // ... }; // predefined policies const size_t default_policy_id = 0; const size_t fast_policy_id = 1; template <> struct policy_traits<fast_policy_id> : public policy_traits<default_policy_id> { static const bool check_domain = false; // overwrite check_domain }; // a simple size_t wrapper template <size_t ID> struct policy { static const size_t value = ID; }; typedef policy<fast_policy_id> fast_policy; } } Users then could define their own policies by providing a new specialization of the policy_traits class for their (unique) ID and would call the special functions similar to quantile( poisson(100), 0.05, fast_policy ); This would avoid the complicated meta-programming you suggested without compromising on the level of control. Regards, Stephan