Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P1673R12: LWG comments from chat #390

Open
mhoemmen opened this issue Jun 15, 2023 · 0 comments
Open

P1673R12: LWG comments from chat #390

mhoemmen opened this issue Jun 15, 2023 · 0 comments

Comments

@mhoemmen
Copy link
Contributor

Varna 2023 LWG comments from chat

Regarding abs, conj, imag, and real

LWG was concerned about the following wording in [linalg.general].

Within all the functions in [linalg], any calls to abs, conj, imag, and real are unqualified.

A suggestion was to reuse the wording form used in [contents] p3 at the end, like the following.

Throughout the specification in [linalg], the meanings of the unqualified names abs, conj, imag, and real are established as-if by performing argument-dependent lookup (6.5.4)."

LWG's impression of the intention is that abs, conj, imag, and real are selected via overload resolution on a candidate set that includes:

  • the correspondingly named functions defined in <cmath> ([cmath.syn]), and
  • the lookup set produced by argument-dependent lookup (6.5.4).

I clarified that the abs / conj / imag / real machinery in P1673 exists for the following reasons.

  1. For custom types, use ADL to find the functions.
  2. For custom types, assume that if conj, imag, or real can't be found via ADL, then the type represents a non-complex number.
  3. For Standard types, "fix" behavior of existing <cmath> etc. functions (e.g., so that abs of an unsigned integer is the integer, and conj of a real number doesn't have complex type).

P2642R2

LWG was concerned that the wording says "apply all wording from P2642R2," but P2642R2 is still in LEWG review. This wording replaced some mdspan layouts that were originally in the proposal. I think P2642 is completely separable from P1673, so we might not even need this.

Fix declaration form of exposition-only concepts

In [linalg.syn], replace patterns like this:

template<class T>
    concept in-vector; = // exposition only

with

template<class T>
    concept in-vector = _see below_; // exposition only

Fix [linalg.general]

[linalg.general] (1.2) and (1.3), change

The pattern xT should be read as “the transpose of x.”

to the following (as "should" sounds like implementations could ignore it):

The pattern xT has the meaning “the transpose of x."
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant