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: 2024-10-03
Priority: Not Prioritized
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.
Proposed resolution: