Thanks, Tom. I'd like to offer an observation regarding P2098. Since the template specializations of std::complex<T> were removed in C++23, std::complex<float> instantiates the primary template. So it may not be immediately obvious that the following is true: std::is_specialization_of_v<std::complex<float>, std::complex> Also, considering the following, struct MyFloat { uint64_t data[8]; }; using T = std::numeric_limits<MyFloat>; static_assert(not T::is_specialized); static_assert(std::is_specialization_of_v<T, std::numeric_limits>); perhaps teachability and the readability of user code could be improved by some other name. One thought that comes to mind is std::is_instance_of_v<T, std::numeric_limits> Regards, Paul -----Original message----- From: Tom Honermann <tom_at_[hidden]> Sent: Monday, November 20 2023, 9:21 am To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: Paul Caprioli <paul_at_[hidden]> Subject: Re: [std-proposals] Complex type traits Previous proposals have explored such traits. See: P2078 <https://wg21.link/p2078>: Add new traits type std::is_complex<T> P2098 <https://wg21.link/p2098>: Proposing std::is_specialization_of Progress on P2078 is blocked on further work by its author. Progress on P2098 is blocked on a proposal that doesn't have the limitations described in the paper. I believe the adoption of P2989 (A Simple Approach to Universal Template Parameters) <https://wg21.link/p2989> would suffice to enable std::is_specialization_of to be implemented as a library feature without such limitations. P2989 is making its way through the committee process now (expected to be reviewed in EWG pending a new revision by its authors). Tom. On 11/19/23 9:34 PM, Paul Caprioli via Std-Proposals wrote: I'd like to float the idea of complex type traits, specifically `add_complex_t<T>`, `remove_complex_t<T>`, and the boolean `is_complex_v<T>`. Since a pointer to an element of an array of `std::complex<T>` can be reinterpreted as a pointer to `T` (with the real-valued array having twice as many elements), some codes use the former and others the latter. So, templated code in libraries and suchlike may want to work with either. My actual use case is FFTs, which can take real or complex arrays and real-valued scaling factors. The functions taking complex-valued arrays can accept `T*`. The scaling factor must be real, not complex. If you are curious about this in particular, my web page is https://hpkfft.com <https://hpkfft.com> and the type traits are here: https://hpkfft.com/hpk/complex_type_traits.html <https://hpkfft.com/hpk/complex_type_traits.html> Are these type traits generally useful enough for std? This question has nothing to do with FFTs. A motivating example might by `axpy()`, which multiplies the real-valued scalar `a` to each element of the array `x` and adds this to the array `y`. The array elements can be, say, `float` or `std::complex<float>`, but the scalar `a` has to be `float`. Note that the arrays can be arrays of real values or arrays of complex values, and if complex values, the type can still be `float*` with the understanding that the real and imaginary parts are interleaved. The same implementation works. If `a` were complex, then a different implementation would be needed. Regards, Paul