Differential D5942
[libcxx] Support UDTs convertible to arithmetic types in <cmath> Authored by K-ballo on Oct 23 2014, 2:24 PM.
Details
This patch enables generic <cmath> overloads for types unambiguously convertible to any arithmetic type. Addresses PR18218. Only pow is implemented completely, with proper noexcept specifications and the conversion dance, taken from Howard's original patch. If it looks good I'll extend the implementation and test cases to all the other generic <cmath> overloads.
Diff Detail Event TimelineComment Actions The __promote and lazy_enable_if changes have already gone into libc++ (I believe) as part of another patch.
Comment Actions This patch reverts the incorporation of __lazy_enable_if, as this is a more general solution. It implements __numeric_type in a SFINAE-friendly fashion, which will flag ambiguously convertible UDTs (as well as other soft errors) as non-numeric types.
Comment Actions The problem I see with this patch is that the expression we use to check for convertibility in __numeric_type is often very different from the expression that actually performs the conversion. The expression that checks for convertibility is: __numeric_test(declval<T>()); and the expression that actually converts T is: static_cast<T>(t); First, we are checking for implicit conversions and preforming explicit ones. This causes a hard compile error in the following code: struct ImplicitExplicit
{
operator float() { return 0.0; }
private:
explicit operator double() { return 0.0; }
};
// Doesn't fire
static_assert(is_same<
__numeric_type<ImplicitExplicit>::type,float
>::value, "");
ImplicitExplicit value;
// Fails to compile.
double d = static_cast<double>(value);
// Example in cmath:
std::isless(value, (float)0.0); // Compiles
std::isless(value, (double)0.0); // Doesn't compile.Second, we are checking for conversions with rvalue references and preforming conversions with lvalue references. This causes a compile error in the following code: struct RValueConvertible
{
operator double() && { return 0.0; }
};
// Doesn't fire.
static_assert(__numeric_type<RValueConvertible>::value, "");
// Example of error in cmath
RValueConvertible value;
std::isnan(value); // Doesn't compile.Third we copy/move the actual types into the cmath functions before preforming the conversion, but we probably shouldn't do this. The following code will not compile for this reason struct NonCopyable
{
NonCopyable() {}
operator int() { return 1; }
private:
NonCopyable(NonCopyable const &);
};
static_assert(__numeric_type<NonCopyable>::value, ""); // Doesn't fire
NonCopyable value;
std::isnan(value);I'm not sure these problems should hold this patch up, but I would like to see some discussion on it before moving forward.
Comment Actions Addressed review comments. Keep in mind that only pow is implemented completely, once we get that one right I'll update the others to follow. | |||||||||||||||||||||||||||||||
Why does pow have the noexcept clause on it anyway?