it only took us until 2026 to formally specify what values a float can represent. by C++35 we should have networking AND a definition of what a number is. maybe.

great paper. any news on networking?

It is not specified what values a floating-point type may represent in C++

That opening line has been true since 1998. But §3.11 is where it gets spicy. The paper explicitly states that numeric_limits<float>::infinity() + 0 is — direct quote — “UB by omission” or “UB by wording hole” even if float adheres to ISO/IEC 60559. “Adheres to” has always meant value representation only, not that C++ arithmetic maps to IEC 60559 operations.

Every test suite that ever checked std::isinf(std::numeric_limits<float>::infinity() + 0.0f) was testing implementation mercy, not a standard guarantee. It works because GCC, Clang, and MSVC all do what IEC 60559 says without being required to.

The fix here is intentionally narrow: define what “adheres to” means, mandate the sign-flip behavior of unary - on zero, and explicitly leave C++ operation semantics to a future paper. Surgical. The right call given the wording debt.

The §6.4 change is the quietest one with the most interesting implementation story. Before this paper, [temp.type] said values of floating-point type must be “identical” for template-argument-equivalence — P1907R1’s vague 2019 patch. Every compiler implemented it as “bitwise identical” since C++20, mangling the bit representation as an integer into the symbol name. This paper just makes that the standard requirement.

Consequence:

template <float V> struct box {};

// Two qNaN values: same IEEE 754 value, different bit patterns
using a = box<std::bit_cast<float>(0x7fc00000)>;
using b = box<std::bit_cast<float>(0x7fc00001)>;

static_assert(!std::is_same_v<a, b>); // passes: GCC, Clang, MSVC

These are distinct instantiations. GCC and Clang both mangle _Z3boxILf7fc00000EE and _Z3boxILf7fc00001EE as separate symbols. The new “bitwise identical” definition in [basic.fundamental] codifies this. Before P3938R1, the standard said “identical” and left you to guess whether that meant IEEE 754 value identity or bitwise identity. Now it’s explicit.

The implication for NaN-payload-encoded constants — think NaN boxing for type-tagged metadata in template contexts — is real. This is the right call.

Edit: 0x7fc00000 is the canonical quiet NaN for binary32, not a signaling NaN. The hex is correct.

meanwhile in Rust: f32 doesn’t implement Eq because NaN != NaN. The PartialEq/Eq split forces you to acknowledge that float comparison is partial. No paper needed, no committee, no wording debt. Just type system design from 2015.

The paper buries the lead in §3.10: floating-point types may represent implementation-defined values beyond NaN, infinity, and finite numbers. The example is VAX FP_ROP — a “reserved operand” that traps when you try to process it, like integer divide-by-zero but for floats. NetBSD documents it: https://man.netbsd.org/NetBSD-10.1/fpclassify.3

So your fpclassify can return a value that isn’t FP_NORMAL, FP_SUBNORMAL, FP_ZERO, FP_INFINITE, or FP_NAN. It can return FP_ROP. The C++ standard has silently permitted this since forever because it inherits fpclassify from C’s <math.h>, which explicitly allows implementation-defined classifications. P3938R1 is the first C++ paper that actually writes this down.

If you write a floating-point classifier that assumes fpclassify can only return five categories, you have a latent bug on VAX targets. Which, granted, you probably don’t have. But the principle stands: the standard’s five-category model was never exhaustive. Now it says so explicitly.

committee gonna committee. seven years of C++20, three years of C++23, and we are now writing down things every implementer has known since the 80s. I respect it. the wording machine grinds slow but it grinds. at least it is not another paper proposing to make signed integer overflow defined behavior.

The has_signaling_NaN / is_iec559 contradiction fix in §6.5 is overdue. On WASM targets, GCC and Clang both report is_iec559 = true for float while simultaneously reporting has_signaling_NaN = true — even though every WASM f32 instruction canonicalizes NaNs, making sNaN indistinguishable from qNaN in practice.

I have wanted to fix this for two years and could not do it unilaterally without breaking conformance with is_iec559. The new note in [numeric.limits.members] permits implementations to treat all sNaN as qNaN “even for types that adhere to ISO/IEC 60559.” That’s the carve-out we needed. Finally official permission to not pretend WASM has signaling NaNs when it functionally does not.