> If one is a typedef for the other, I can't create overloads, meaning I
have to #if my code on something.

That's a fair point. But I think in usual case, the need for preprocessor conditional directives is only necessary in case the standard floating point types do not alias to an IEC60559. In other words, the standard floating point overloads should be provided unconditionally in a library, and extended floating point overloads may be provided but only if such types are provided by the implementation and they are known to be different from the standard floating point types. In any cases, a preprocessor conditional directive will be necessary for for each individual extended floating point types provided by the implementation because those are optional and may not even be available.

In most cases (i.e. when float is float32_t, double is float64_t an long double is float128_t), exposing only the standard floating point overloads would be sufficient to cover both the standard and the f32, f64, f128 iec formats, and there would be no need for conditionally exposing those extended floating point overloads. For me that seems like less copy paste coding and less conditional preprocessor directives. (float16_t could be coalesced similarly if we had a short length modifier for float).

Unfortunately, with ieee extended types being strong aliases, support for fixed ieee types requires deduplicated source and machine code even if some of those types were actually supported through standard floating point types.

On August 27, 2025 11:33:15 p.m. EDT, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Wednesday, 27 August 2025 18:50:54 Pacific Daylight Time Julien Villemure-
>Fréchette via Std-Proposals wrote:
>> The argument in P1467R9 that the get_exponent function below is moot on a
>> IEC559 platform. int get_exponent(double x) { /* ... */ }
>> int get_exponent(std::float64_t x) { /* ... */ }
>>
>> If both double and std::float64_t have identical representation, behavior
>> and intent, then I expect both overloads of get_exponent will have
>> identical function body implementation with indistinguishable behavior for
>> every pair of equivalent double/std::float64_t inputs. This situation makes
>> overloading both useless, and a burden: implement identical code with
>> identical behavior for types with identical behavior and identical
>> representation. Not to mention all possible function signatures using
>> double would often also need to be deduplicated.
>
>Indeed but you can turn the argument around: suppose I am writing some mostly-
>generic content and I don't *know* whether double and float64_t are the same or
>not. If one is a typedef for the other, I can't create overloads, meaning I
>have to #if my code on something.
>
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering