> We have magic aliasing properties for std::complex exactly to bridge some interoperability issues. > I don't really advocate for more magic, I would rather have a generic framework for having distinct types that can alias each other. > Then we can more freely decide for newly introduced types whether aliasing makes sense or not. Who is "we"? Are you suggesting a generic framework that allows programmers to pick and choose which distinct types can alias each other? It seems adding such capability to the standard library would lead to a great deal of undefined behavior, as it would be easy to violate the one definition rule. Also, there would be a temptation to unconditionally alias `double` and `std::float64_t` without checking whether the former is IEEE binary64. Practically speaking, it's a safe assumption, but then why have `std::float64_t` at all? The C++ standard can alias the two types if and only if they both have the same representation. Or may I assume that "we" is the C++ committee? But then the generic framework is just words in the standard that compilers have to honor, i.e., magic. I agree it's important to make the words clear, and it seems "designates" is the magic word. As in, `reinterpret_cast<cv T*>(a)[2 * i]` designates the real part of `a[i]`. I also agree that newly introduced types should carefully consider whether aliasing makes sense or not. Referring to my earlier email, developers using daxypy want to write: daxpy(n, alpha, (std::float64_t*)(x.data()), (std::float64_t*)(y.data())); I predict that is how programs using `double` will access third-party libraries taking pointers to `std::float64_t`. We can: (1) Update the C++ standard to make that work. (2) Ignore that it is currently UB and rely on compilers to make it work anyway. (3) Educate programmers not to mix `double` and `std::float64_t`. (4) Educate programmers to memcpy x.data(), memcpy y.data(), call daxpy(), start_lifetime_as_array<double> on the returned array, and then y.assign(). I suggest that (3) and (4) are equivalent to saying, "never use `std::float64_t`." Modern scientific codes rely on "icebergs of dependency libraries." See slides 7-8 of https://spack-tutorial.readthedocs.io/en/latest/_downloads/91891ebe189765703c6acb6a59528a15/spack-hpcic25-tutorial-slides.pdf Best regards, Paul