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
Use consistent terminology when referring to what a pointer to member points to #3828
base: main
Are you sure you want to change the base?
Conversation
We need to decide which word we want to use here. I've asked CWG for opinions. |
Conclusion from committee discussion: use "designates" to describe the relationship between a pointer-to-member value In |
Some specific examples for the case of referring to the member type:
|
@zygoloid Alright, I went ahead and applied the changes. In addition to this, I restructured [expr.mptr.oper] to more closely follow the layout of [expr.ref], and condensed the wording (we had requirements placed on operands all over the place, and it appears that there was an attempt to make the subclause more like [expr.ref], but it was never fully completed) |
Just noticed that we have no normative wording that says the |
"mutable" is not part of the pointer-to-member type, so why would the pointer-to-member operators care? |
|
For clarity, could you please show an example? |
or | ||
``\cv{}~\tcode{void}''. | ||
A pointer to member shall not designate a static member | ||
of a class\iref{class.static}. |
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.
This restriction seems redundant; how could the "static member" situation ever arise?
&C::static_member yields a regular pointer, not a pointer to member.
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.
True; I didn't want to drastically change it too much, be this can certainly be turned into a note saying something along the lines of: "A pointer to member designating a static member cannot be formed as there is no syntax to do so."
In a pointer-to-member expression of the form \tcode{E1->*E2}, \tcode{E2} shall | ||
be of type ``pointer to member of \tcode{T}'' and \tcode{E1} shall be of type | ||
``pointer to \cv{}~\tcode{U}'' where \tcode{U} is \tcode{T} or a type of which | ||
\tcode{T} is an accessible and unambiguous base class. The expression is converted |
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.
This seems to be redundant with the checks after the rewrite.
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.
My intent was to allow for the reader to clearly reason the requirements on the operands, but this could be replaced with:
In a pointer-to-member expression of the form
E1->*E2
,E1
shall be a prvalue of pointer to object type. The expression is converted to the equivalent form(*(E1)).*E2
; the remainder of this subclause will
address only the operator.*
.
|
Currently, a mixture of "points", "refers", "selects", "designates", and "denotes" is used when referring to what a pointer to member points to. While pointer to members aren't the same as pointers, they certainly are "pointers" in the sense that an object or function can be obtained through them via indirection, hence the replacement with "points to" in this PR. Additionally, we already use "refers to", "designates", and "denotes" for glvalue expressions, so this clears up any ambiguity.