Brian Bi made some points earlier in this thread: > we don't allow it between, say, `long` and `long long` even if they have the same representation (e.g. 64 bits, little-endian, with no padding bits) If double and std::float64_t are allowed to alias, why not long and long long? Maybe the right answer is to allow both (i.e., if double and std::float64_t have identical representations they can alias each other, and if long and long long have identical representations they can alias each other). > There are two main objections to extending the list of exceptions to the strict aliasing rule. Some people don't like it ideologically: they feel that it weakens the type system and concedes ground to the side that prefers to view objects as bags of bits. I'm sympathetic to this. Maybe it should not be the deciding factor, however. 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. I'm not saying the choice was wrong; I'm just confessing my ignorance. Would allowing aliasing (in the sense of making reinterpret_cast work) undermine the reasons for making them different types? I don't know. > Others are unwilling to give up the optimizations that are enabled by strict aliasing rule (e.g. the compiler being able to assume that a write to a `long` glvalue cannot change the result of a subsequent read from a `long long` glvalue). For floating-point, I do NOT see such optimizations as valuable. If a program mixes double and std::float64_t, it's being done willy-nilly, to satisfy the API of external libraries. In fact, when the following fails to compile: daxpy(n, alpha, x.data(), y.data()); programmers will simply write: daxpy(n, alpha, (std::float64_t*) x.data(), (std::float64_t*) y.data()); and it will work. Years later, it may stop working, and somebody will file a compiler bug. Or, they'll use different compiler flags so as to hide the problem. Or, they won't notice and bridges will collapse. Alternatively, nobody will use std::float64_t for anything. For each individual, using it would be seen as a more trouble than it's worth. -----Original message----- From: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> Sent: Tuesday, August 26 2025, 1:55 pm To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: Sebastian Wittmeier <wittmeier_at_[hidden]> Subject: Re: [std-proposals] TBAA and extended floating-point types I can understand some general reasons for the push-back on allowing aliasing. But specifically double and std::float64_t on platforms, where they have the same representation: What is gained by disallowing aliasing? Wouldn't it just be defined as a typedef on those platforms? You find yourself agreeing (with disallowing), can you explain? -----Ursprüngliche Nachricht----- Von: Paul Caprioli <paul_at_[hidden]> There is push-back on allowing aliasing (i.e., on prohibiting TBAA optimizations based on double and std::float64_t being different types). Unfortunately, I find myself agreeing. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals