LEWG started reviewing P3050R2 (Fix C++26 by optimizing linalg::conjugated for noncomplex value types) on 2024-08-27 but didn't finish.
Summary of LEWG's 2024-08-27 discussion
Definition of a (non)complex number type
P3050 follows [linalg], specifically conj-if-needed(E), which is defined as
ADL-found conj(E) if type of E is not an arithmetic type, else
E.
conj already is not ADL-findable for double, etc., which is what we want anyway.
Custom real types and conj
What happens if a user defines conj for their custom real type?
Results will be mathematically correct if user defined it mathematically correctly.
Best case: return type same as input type: custom_real conj(const custom_real&)
Avoids mixed-type computations if all matrices and vectors are custom_real
Worst case: user imitates std::conj by defining custom_complex<custom_real> conj(custom_real)
Code may fail to compile if user did not define the right mixed arithmetic operators and/or implicit conversions (but that's the user's fault; they did ask for conjugate_transposed(A))
Users are already outside the space of typical std::linalg optimizations. Best they can expect is std::execution::par_unseq.
Users may have custom linear algebra algorithms and may use them with std::linalg::conjugated and/or std::linalg::conjugate_transposed, though.
Consider a follow-on proposal to deprecate and replace std::conj
I am not bothered if users write a custom real number type and they define ADL-findable conj to return the custom complex of their real type because that’s weird.... The existing behavior of the Standard is broken. Anyone who works with complex numbers hates this.
Consider a follow-on proposal to deprecate std::conj and define a new std::conjugate more rationally
Should this wait for language support for customization points?
LEWG review of P3050R2
LEWG started reviewing P3050R2 (Fix C++26 by optimizing
linalg::conjugatedfor noncomplex value types) on 2024-08-27 but didn't finish.Summary of LEWG's 2024-08-27 discussion
Definition of a (non)complex number type
P3050 follows [linalg], specifically
conj-if-needed(E), which is defined asconj(E)if type ofEis not an arithmetic type, elseE.conjalready is not ADL-findable fordouble, etc., which is what we want anyway.Custom real types and
conjWhat happens if a user defines
conjfor their custom real type?Results will be mathematically correct if user defined it mathematically correctly.
Best case: return type same as input type:
custom_real conj(const custom_real&)custom_realWorst case: user imitates
std::conjby definingcustom_complex<custom_real> conj(custom_real)Code may fail to compile if user did not define the right mixed arithmetic operators and/or implicit conversions (but that's the user's fault; they did ask for
conjugate_transposed(A))Users are already outside the space of typical std::linalg optimizations. Best they can expect is
std::execution::par_unseq.Users may have custom linear algebra algorithms and may use them with
std::linalg::conjugatedand/orstd::linalg::conjugate_transposed, though.Consider a follow-on proposal to deprecate and replace
std::conjConsider a follow-on proposal to deprecate
std::conjand define a newstd::conjugatemore rationallyShould this wait for language support for customization points?