If this is separate from numeric_limits, we may want a more general
iec559_traits template that not only provides the format classification,
but parameters such as the total width of the format, the exponent and
mantissa bit counts, the exponent bias, whether binary or decimal encoding
is used for a decimal interchange type, etc.

There would obviously be some overlap with numeric_limits, but I don't
think that's much of a problem.

On Thu, 16 Apr 2026 at 11:37, Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Thu, 16 Apr 2026 at 10:27, Jan Schultke via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> We ought to have some portable way to classify a floating-point type
>> according to its ISO/IEC 60559 format. For example, one may want to detect
>> at compile time whether float has the same representation as
>> std::float32_t, and other such things.
>>
>> Merely checking whether the type is 32 bits large and is_iec559 is true
>> doesn't necessarily work. The floating-point type could also be in an
>> extended 16-bit format, or in an interchange format that also has 32 bits
>> but is not binary32, or it could be binary16 with 16 bits of padding. A
>> perfectly reliable approach (that doesn't involve querying all sorts of
>> other properties like the number of digits and the exponent) would look
>> like:
>>
>> enum class iec559_format : /* unspecified */ {
>>
>> unclassified,
>>
>> binary_arithmetic, // e.g. x87 80-bit long double;
>>
>> // has inf, qNaN, sNaN, and can represent numbers,
>>
>> // but is not an interchange format
>>
>> binary_interchange, // generic binary interchange format,
>>
>> // e.g. binary256 or binary512
>>
>> binary16, // basic binary interchange format (std::float16_t)
>> binary32,
>> binary64,
>> binary128,
>> binary16x, // extended format for binary16 (C23 _Float16x)
>> binary32x,
>> binary64x,
>> binary128x,
>>
>> decimal_arithmetic,
>>
>> decimal_interchange, // generic decimal interchange format
>> decimal32, // basic decimal interchange format
>> decimal64,
>> decimal128,
>> decimal32x, // extended format for decimal32 (C23 _Decimal32x)
>> decimal64x,
>> decimal128x,
>> };
>>
>>
>> The user could use this as follows:
>>
>> constexpr auto f = std::numeric_limits<T>::iec559_format;
>> if constexpr (f == std::iec559_format::binary32) {
>> // always true for std::float32_t, usually true for float
>> }
>> if constexpr (f == std::iec559_format::binary64) {
>> // always true for std::float32_t, usually true for double,
>> // sometimes true for long double
>> }
>>
>>
>
> This should be a separate trait, not a new member of std::numeric_limits.
>
> Adding a new member breaks every program-defined specialization of
> std::numeric_limits, and the direction is to split numeric_limits into
> individual pieces, not as a monolith.
>
>