I don't like the idea of returning a NaN: returning 1 seems to be the right thing to do, and should probably be the default behaviour? The other problem with reusing a domain_error is that the default behaviour is to throw an exception, which may not be what users expect for this corner case?
Originally I wanted to bypass that default behavior by having the second overload of pow calling the first one with a precise policy rather than just policy<>(). But this may not be a good approach (users could be surprised to not have the same result by calling pow<N>(x) than by calling pow<N>(x, policy<>()) ).
So I guess I'm leaning towards yet-another error-action, "zero_power_error" maybe?
Are you talking about an action or a policy? If it's an action, having an action dedicated to this case is weird since it won't apply to anything else than a domain_error (if we finally use that). If it's a policy, having a policy dedicated to one single function of the library sounds bad to me too. Why not be more general and call it "undetermined_result_error" or something else that doesn't interfere with any other policy and could eventually apply to more situations?
<snip>
Personally I can't help wondering if they just overlooked the 0^0 case :-(
Indeed they seem to contradict themselves a bit...
Grrr, still not sure what to do here, how about:
* If the domain_error action is "ignore_error" then return 1, otherwise, * Raise a domain_error as normal.
I had thought about this solution but didn't know 1) if the framework allows this kind of test easily and safely, and 2) if it doesn't break the general philosophy of policies in Boost.Math (a bit like doing type testing in OO). But if you think it's possible, why not... I'm like you, really not sure of what to do... I'll continue to think about all that. Bruno