On Mon, Aug 25, 2025, at 23:19, Paul Caprioli via Std-Proposals wrote:
> Given std::vector<double> x(40);
> suppose we allowed: std::span<std::float64_t, 40>(x);
>
> Philosophically, I want a non-owning view of the data, so maybe
> std::span is a good choice?
> I don't want actual conversion; I think I'd prefer compilation to fail.

There are two questions here.

First is are we forcing that double and float64_t are both the same bit repreresentaiton? There are many who want std::float64_t to be ieee-754, even if the hardware is different. I know ieee-754 is from 1985 and nearly everyone uses it and thus double is for paractial purposes ieee-754, but are we forcing that (or maybe stating std::float64_t is implementation defined representaiton with only 64 bits guarenteed)? Will some hardware guy come up wih a new/differnet layout next year that is not bit compatible, but "better" by enough that some people want to use it instead. Is there any other reason double and std::float_64_t might have a different bit representaiton despite both being 64 bits. Double isn't forced to 64 bits (well it wasn't last I checked but that has been a while), what happens if it is different?

If floating point might be something else (either in the future, on maybe on esoteric hardware nobody in this discussion is aware of) then we need to figure out how casting works. Do we say static_cast will convert between the two, or make it a compiler error if the implementation doesn't use the same bit representatoin for both.

The second question is when the implementation knows the underlying bit representation is exactly the same do we allow aliasing. double/std::float64_t, the various int types... I know my implementation so can I take advantage of that?

> The compiler would have to understand that these two particular objects
> alias even though the elements have different types.
> But that's nicer than prohibiting TBAA of all doubles and
> std::float64_ts.
>
>
> -----Original message-----
> From: Sebastian Wittmeier <wittmeier_at_[hidden]>
> Sent: Monday, August 25 2025, 2:05 pm
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>;
> Paul Caprioli <paul_at_[hidden]>
> Subject: AW: [std-proposals] TBAA and extended floating-point types
>
> Perhaps we need bit_cast or other conversions for arrays and templated
> containers. Either as noop or as actual conversion.
>
> ranges? adapter classes? Do we have enough facilities?
>
> -----Ursprüngliche Nachricht-----
> Von: Paul Caprioli <paul_at_[hidden]>
> Gesendet: Mo 25.08.2025 22:03
> Betreff: RE: [std-proposals] TBAA and extended floating-point types
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
>> What about bitcast instead?
>
> I'm thinking about the following, and don't see how bitcast is useful:
>
> void daxpy(std::size_t n, const std::float64_t alpha, const std::float64_t* x,
> std::float64_t* y) {
> for (std::size_t i = 0; i < n; ++i) y[i] += alpha * x[i];
> }
>
> int main() {
> std::size_t n = 40;
> double alpha = 2.0;
> std::vector<double> x(n, 1.0);
> std::vector<double> y(n, 3.0);
>
> daxpy(n, alpha, x.data(), y.data());
>
> std::cout << y[17] << '\n'; // UB
> }
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals