[ 2025-02-07; Reflector poll ]

Set priority to 3 after reflector poll.

"Program-defined specializations of `std::complex` (i.e. explicit specializations and program-defined partial specializations) seem unsupportably broken. We should say so explicitly until somebody writes a paper to fix them."

std::complex<NonFloatingPoint> is possibly a program-defined specialization and thus instantiation of such a specialization can have determined effect. However, it's improbable for implementations to ensure that some free functions, e.g. abs, sin, exp, work for such a specialization.

Moreover, P2819R2 made all std::complex specializations tuple-like types, despite that std::get overloads need to touch implementation details and thus don't work for program-defined specializations.

It seems better to make only complex<floating-point> tuple-like types, and add Constraints to some free functions that can't be guaranteed to work to only accept cases where T is a cv-unqualified floating-point type. However, it's unclear to me how to handle cases where the implementation intentionally supports complex<X> (where X is not a program-defined type) as extension, and whether Mandates should be used.