Hubert Holin wrote:

The proposed interface is certainly nice and could definitely be worked with.

OK good.

For the global choices it is perfectly adequate, IMO. For finer control however, it does appear very fine-grained (per-function), which, in addition to making error message harder to read, is perhaps not the most frequent level of interaction needed. For instance, while I certainly see the need sometimes for per-function disabling of internal double promotion, I believe that more frequently users may want to set these preferences at the translation unit level, when not at the global level.

Whilst I think you're correct that per-TU control is the most often needed requirement: it's actually the hardest of all to provide without violating the dreaded "one definition rule". The only solution I can think of involves making the special function macros - which also means we can't overload them - and then internally mangling the function names according to the policies in effect (in other words the same as the current proposal). Perhaps more interesting, and based on the current proposal is per-namespace policies: #include typedef something my_policy_type; namespace mynamespace{ BOOST_MATH_DECL_POLICY_SPECIAL_FUNCTIONS(my_policy_type); } Then "mynamespace::tgamma(x);" would use my_policy_type to determine it's behaviour. If you an unnamed namespace then this could be used in place of a using declaration, to bring a specific set of functions into the scope of the current TU only.

While (mostly) global objects may be evil, something along the lines of standard streams and their interaction with locales and facets may perhaps be easier to deal with. For instance, functions may requests their choices from some external "policy object", which may be locally altered, much as streams will enquire from a locale how to typeset dates. Granted, this would make multithreading all the hairier (which is not really a good idea).

Oh, no global objects please, they're evil, no really they are! :-)

On the other hand, not all functions necessarily require information about every configuration choice possible, so passing in all the info when only some is needed may perhaps be excessive.

That's true. However, I now have the meta-programming code that allows a function to reset policies that it knows aren't relevent to it to their defaults. Policy objects also get "normalised" internally to reduce code bloat, so: tgamma(x, policy1); and tgamma(x, policy2); are one-line inline forwarders that will call the same template instantiations internally, if there are no relevent differences between policy1 and policy2. Thanks for the feedback, John.