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

[expr.prim.lambda.capture] vs. [basic.def.odr] in their use of «names»/«named by» #5243

Open
languagelawyer opened this issue Jan 30, 2022 · 1 comment · May be fixed by #5254
Open

[expr.prim.lambda.capture] vs. [basic.def.odr] in their use of «names»/«named by» #5243

languagelawyer opened this issue Jan 30, 2022 · 1 comment · May be fixed by #5254

Comments

@languagelawyer
Copy link
Contributor

[expr.prim.lambda.capture]/7:

an id-expression that names one or more non-static class members and does not form a pointer to member ([expr.unary.op]) potentially references *this.
[Note 3: This occurs even if overload resolution selects a static member function for the id-expression. — end note]

The issue is that the normative part (plural «more non-static class members») and the Note are not compatible with [basic.def.odr], which says that

A function is named by an expression or conversion as follows:
— A function is named by an expression or conversion if it is the selected member of an overload set

P.S. Why the first bullet in [expr.prim.lambda.capture]/7 uses semicolon? I think it should be just split into two bullets.
@xmh0511
Copy link
Contributor

xmh0511 commented Feb 3, 2022 •
edited

Presumably, the verb "names" has a different meaning in [expr.prim.lambda.capture] p7 and [basic.def.odr]. In [expr.prim.lambda.capture]/7, "name" should also cover data membe but [basic.def.odr] merely defines the "named by" for the variable and function

A variable is named by an expression if the expression is an id-expression

A non-static data member is not a variable. Thus, "name" or "named by" cannot apply to data member. Analogously, "name" defined for function cases in odr does not intend to apply to member function in [expr.prim.lambda.capture] p7. I think the verb "name" should be improved here since it has been given different meaning in the two clauses.

@languagelawyer languagelawyer linked a pull request Feb 6, 2022 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[expr.prim.lambda.capture] Fix 'potentially references' for members languagelawyer/draft
2 participants
@xmh0511 @languagelawyer