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 ishttps://hpkfft.com and the type traits are here: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