-
Notifications
You must be signed in to change notification settings - Fork 752
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
P3050R2 Fix C++26 by optimizing linalg::conjugated for noncomplex value types #7493
Conversation
aeb4319
to
f4e35e8
Compare
\tcode{Accessor} if the expression \tcode{conj(E)} is not valid for any subexpression \tcode{E} | ||
whose type \tcode{T} is expression-equivalent to \tcode{remove_cvref_t<ElementType>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A type cannot be expression-equivalent. I'm not sure what the paper's intent actually was here, E is simply not defined well. Should it really be an rvalue, as this wording kinda implies? That doesn't seem right to me. I think we need input from @mhoemmen or LWG.
This also introduces two types T
, the one that is the type of E
and the template parameter of the conj
poison pill, which is a bit confusing, but that problem is already present throughout [linalg.helpers].
\tcode{Accessor} if the expression \tcode{conj(E)} is not valid for any subexpression \tcode{E} | |
whose type \tcode{T} is expression-equivalent to \tcode{remove_cvref_t<ElementType>} | |
\tcode{Accessor} if the expression \tcode{conj(E)} is not valid for any subexpression \tcode{E} | |
of a type similar to \tcode{remove_cvref_t<ElementType>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened #7494 for the T reuse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do let's follow up asap, but I'll merge the motion application as is for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhoemmen in case you missed this one (I think I spelled your username wrong at first and I don't think github resends emails after comments are edited)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jwakely FYI, this issue refers to R2, but it was R3 that was approved by LWG on 2024-10-25. That might have wording differences.
…ue types Editorial notes: * The editing instructions in the paper are rather unclear. We have applied the wording of the paper and replaced the original wording entirely, since the paper does not indicate deletions and insertions. Future versions of this draft may start rejecting instructions of such deficiency. * The leading words "the value" have been inserted in a "Returns:" element consisting of a list where the list items would otherwise have started with a codeblock (which does not get formatted correctly). * The feature test macro value is bumpted to 202412, since the previous motion (P3222R0) already uses 202411.
f4e35e8
to
1fa2078
Compare
Fixes cplusplus/papers#1719.
Fixes #7422.