P3050R2: LEWG review 2024-08-27 and 2024-09-03

[mhoemmen]

LEWG review of P3050R2

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

1. ADL-found conj(E) if type of E is not an arithmetic type, else
2. 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?