X2

std::float64_t being required to be a different type than double is a huge travesty that should have never had been admitted into the standard.

But the problem is it is already standard.
Major compiler vendors are struggling to implement this atm, so it is technically the ship hasn’t sailed yet, and there’s still time to issue an errata. But I don’t think there is a way to do it in time to be helpful.

The C++ standard is littered with problems such as this, and the type system is completely broken.
It needs a major overall of the type system that will break backwards compatibility.


From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Julien Villemure-Fréchette via Std-Proposals
Sent: Thursday, August 28, 2025 03:51
To: std-proposals_at_lists.isocpp.org
Cc: Julien Villemure-Fréchette <julien.villemure_at_[hidden]>
Subject: Re: [std-proposals] TBAA and extended floating-point types

I tend to think the OP rases a legitimate concern, though braking strict aliasing is not the right solution IMO. I rather think std::float64_t should really be a typedef to a standard floating point type (typically double) when and only when that type is an IEC60559 Binary64.

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.

Now on platforms that do not support IEC60559, then it is totally fine to have float64_t be a type distinct from the standard double since, for instance the get_exponent function above might certainly have different implementation, with possibly different.

But at least if the platform is IEC60559, it should really use a standard floating type as a typedef for std::floatN_t.

On August 26, 2025 6:53:48 p.m. EDT, Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

Following up to my own email:

The C++ standard does NOT allow one of double or std::float64_t to be a typedef of the other.
I don't have a clear understanding of why this choice was made.

P1467R9 says the strongest argument against allowing aliasing [in the sense of typedef] of standard types is to allow overload sets such as:

    int get_exponent(double x) { /* ... */ }
    int get_exponent(std::float64_t x) { /* ... */ }

Note that allowing aliasing in the sense of making another exception to the strict aliasing rule so as to allow reinterpret_cast would not affect overload resolution.