On Tuesday, 14 April 2020 11:02:18 -03 Jody Hagins via Std-Proposals wrote:
> The requirements of the original template apply only to the implementation's
> representation of the arithmetic types. Since it is impossible for any
> user-defined type to satisfy this constraint, it is impossible for any user
> defined type to provide a specialization that meets the standard library
> requirements for the original template. Thus, according to the standard
> itself, the behavior of a program is undefined if it adds a template
> specialization for std::numeric_limits.
>
> Don't get me wrong - I would love to see where the standard allows such
> specialization. I'm even somewhat OK with implication, but here there
> seems to be explicit contradiction to such specializations.

We wanted to add a specialisation of std::numeric_limits for qfloat16 as well
as other cmath functions like inf(), fpclassify(), etc. Since doing that was
UB, we had to add them with a q prefix (qInf, qFpClassify, etc.).

In order to write generic code that deals with qfloat16, float and double, we
needed to add the same overloads and specialisations for float and double.

Conclusion: now Qt code has to use qFpClassify() instead of std::fpclassify().

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products