This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
std::complex<NonFloatingPoint>Section: 29.4 [complex.numbers] Status: New Submitter: Jiang An Opened: 2024-09-29 Last modified: 2025-02-07
Priority: 3
View all other issues in [complex.numbers].
View all issues with New status.
Discussion:
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.
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.
[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."
Proposed resolution: