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.
4161. Some free functions don't automatically work for program-definedstd::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:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4