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

Use consistent terminology when referring to what a pointer to member points to #3828

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sdkrystian
Copy link
Contributor

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.

@zygoloid zygoloid added the decision-required A decision of the editorial group (or the Project Editor) is required. label Mar 12, 2020
@zygoloid
Copy link
Member

We need to decide which word we want to use here. I've asked CWG for opinions.

@zygoloid
Copy link
Member

zygoloid commented Mar 19, 2020

Conclusion from committee discussion: use "designates" to describe the relationship between a pointer-to-member value &M::x and the member M::x.

In T M::*, consider calling T the "member type" of the pointer-to-member type (adding a suitable definition) if necessary.

@zygoloid zygoloid added changes requested Changes to the wording or approach have been requested and not yet applied. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Mar 19, 2020
@zygoloid
Copy link
Member

Some specific examples for the case of referring to the member type:

  • Add a sentence "The type T is the member type of the pointer-to-member type." To near the end of [dcl.mptr]p1.

  • "the function type to which a pointer to member refers" in [dcl.fct]p6 would become "the member type of a pointer to member type"

  • "For a call to a non-static member function, the postfix expression shall be [...] a pointer-to-member expression selecting a function member" could be just "For a call to a non-static member function, the postfix expression shall be [...] a pointer-to-member expression of function type".

@sdkrystian
Copy link
Contributor Author

@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)

@jensmaurer jensmaurer removed the changes requested Changes to the wording or approach have been requested and not yet applied. label Apr 10, 2020
@sdkrystian
Copy link
Contributor Author

Just noticed that we have no normative wording that says the mutable specifier is ignored by pointer to member operators. Should we add that to this PR?

@jensmaurer
Copy link
Member

"mutable" is not part of the pointer-to-member type, so why would the pointer-to-member operators care?

@sdkrystian
Copy link
Contributor Author

mutable isn't part of the members type either, it's a property of the declaration. Since the cv-qualification of the pointer to member expression is the same as that of an equivalent class member access expression, the "mutability" of the designed member is still considered.

@jensmaurer
Copy link
Member

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}.
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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 .*.

@sdkrystian
Copy link
Contributor Author

sdkrystian commented May 2, 2020

For clarity, could you please show an example?

struct S
{
  mutable int a;
};

void f()
{
  const S obj;
  auto mem = &S::a;
  obj.*mem = 10;
  // type of obj is const S
  // type of mem is int S::*
  // given a hypothetical class member access expression obj.id where id names the same
  // member mem designates (a), the const qualifier would be removed from the point-to-member 
  // expression because it would also be removed in the corresponding class member access
  // expression as a is declared mutable ([expr.ref] p6.2)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs rebase The pull request needs a git rebase to resolve merge conflicts.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants