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.

Sign up for GitHub

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

Jump to bottom

Mislead utterance of section [expr.mptr.oper] #4703

Open
xmh0511 opened this issue Jun 17, 2021 · 6 comments · May be fixed by #4733
Open

Mislead utterance of section [expr.mptr.oper] #4703

xmh0511 opened this issue Jun 17, 2021 · 6 comments · May be fixed by #4733
Assignees
@jensmaurer

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jun 17, 2021 •
edited

The binary operator .* binds its second operand, which shall be of type “pointer to member of T” to its first operand, which shall be a glvalue of class T or of a class of which T is an unambiguous and accessible base class. The result is an object or a function of the type specified by the second operand.

As aforementioned, the second operand has the type of “pointer to member of T”, but the rule says the result is an object or a function of the type specified by the second operand, Is it a contradiction here?

Maybe we should say

The result is an object or a function of the type specified by the entity to which the second operand refers.

Can E2 be the second operand of the class member access operator?

Abbreviating pm-expression.*cast-expression as E1.*E2, E1 is called the object expression. If the dynamic type of E1 does not contain the member to which E2 refers, the behavior is undefined. Otherwise, the expression E1 is sequenced before the expression E2.

The restrictions on cv-qualification, and the manner in which the cv-qualifiers of the operands are combined to produce the cv-qualifiers of the result, are the same as the rules for E1.E2 given in [expr.ref].

Again, E2 still has the type of “pointer to member of T” in the context of the above rule, which means E2 is invalid to be the second operand of the expression E1.E2.
@jwakely
Copy link
Member

jwakely commented Jun 17, 2021

As aforementioned, the second operand has the type of “pointer to member of T”, but the rule says the result is an object or a function of the type specified by the second operand, Is it a contradiction here?

No. The type specified by the second operand does not mean the type of the second operand.

A pointer to member of type int T::* specifies a result of type int. A pointer to member of type void (T::*)(char) specifies a result of type void(char).

which means E2 is invalid to be the second operand of the expression E1.E2

Yes, that one seems wrong.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 17, 2021 •
edited

As aforementioned, the second operand has the type of “pointer to member of T”, but the rule says the result is an object or a function of the type specified by the second operand, Is it a contradiction here?

No. The type specified by the second operand does not mean the type of the second operand.

A pointer to member of type int T::* specifies a result of type int. A pointer to member of type void (T::*)(char) specifies a result of type void(char).

Please ask which is the normative rule in the standard gives that meaning?

@jwakely
Copy link
Member

jwakely commented Jun 17, 2021

There isn't a rule saying "the type specified by" means "the same type" either, not in the standard and not in English.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 17, 2021

There isn't a rule saying "the type specified by" means "the same type" either, not in the standard and not in English.

Yes, that is what I'm concerning here. The phrase "the type specified by" gives an ambiguous meaning, we can read it in either meaning. So, I think we should replace it with more clear wording to avoid the potential misunderstanding.

@jwakely
Copy link
Member

jwakely commented Jun 17, 2021

If you choose to read the words a certain way, and that creates a contradiction or nonsensical meaning, maybe you shouldn't read them that way.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jun 17, 2021 •
edited

If you choose to read the words a certain way, and that creates a contradiction or nonsensical meaning, maybe you shouldn't read them that way.

Agree with you. But I think we could improve the wording to make it to be more readable. After all, in the other place, such as "T&", we use the utterance "the referenced type" or "the type to which the reference refers" and so on. Have a similar way for pointer type. Why not use a similar tone here instead use the "the type specified by..."?

@jensmaurer jensmaurer self-assigned this Jul 4, 2021
@jensmaurer jensmaurer linked a pull request Jul 4, 2021 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jensmaurer jensmaurer

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[expr.mptr.oper] Clarify pointer-to-member operators. jensmaurer/draft
3 participants
@jwakely @xmh0511 @jensmaurer