cplusplus / CWG

Core Working Group
24 stars 7 forks source link

[basic.lval] p5 An id-expression naming the reference denotes the reference #44

Open xmh0511 opened 2 years ago

xmh0511 commented 2 years ago

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[basic.lval] p5 says

The result of a glvalue is the entity denoted by the expression.

Consider this example:

int a = 0;
int& rf = a;
rf;

In this case, rf is an unqualified-id denoting the reference, per [expr.prim.id.unqual] p3 and [basic.pre] p5. whilst rf is also an lvalue as per [expr.prim.id.unqual] p3. According to [basic.lval] p5, the result of lvalue rf is the reference. However, a glvalue either denotes an object or a function, the result of the lvalue rf should intend to be the object denoted by a. Maybe, we should use "designate" in place of "denote" in [basic.lval] p5, as the following:

The result of a glvalue is the entity designated by the expression.

Everywhere, we should clearly define what entity the expression designates. Such as, we have defined what entity an unqualified-id introduced by a reference declaration designates in [expr.type] p1

The expression designates the object or function ~denoted by the reference~ to which the reference is bound.

Such as changing [expr.unary.op] p1 as the following:

the result is an lvalue ~referring to~ designating the object or function to which the expression points.

languagelawyer commented 2 years ago

This is all part of the entity (variable) vs. object confusion

jensmaurer commented 2 years ago

A plethora of verbs appear to be in use to talk about the object to which a glvalue or a reference refers.

[conv.lval] p3 uses "refers" and "indicated".

[basic.lval] p5 and p11 uses "denotes"

We should use a consistent verb form here.

jensmaurer commented 2 years ago

It seems "denotes" should be used for "the result of name lookup", e.g. a name denotes a variable or a function. See basic.pre p5. We should pick another verb for references and glvalues.

xmh0511 commented 2 years ago

We should use a consistent verb form here.

Yes, this is the concern of this issue. Furthermore, we don't give a consistent meaning to "reference binding" as well.

Consider [dcl.init.ref] p5.1 and p5.3

then the reference binds to the initializer expression lvalue in the first case and to the lvalue result of the conversion in the second case (or, in either case, to the appropriate base class subobject of the object).

In any case, the reference binds to the resulting glvalue (or to an appropriate base class subobject).

So, whether the reference binds to the expression or an entity(i.e. an object or a function)? In [over.ics.rank] subclause, we basically say the reference binds to either an lvalue or rvalue(i.e. the expression).

xmh0511 commented 2 years ago

It seems "denotes" should be used for "the result of name lookup", e.g. a name denotes a variable or a function. See basic.pre p5.

Agree! "denote" is correctly used in [expr.prim.id.unqual] and [expr.prim.id.qual]. First, [basic.pre] p5 says

An entity E is denoted by the name (if any) that is introduced by a declaration of E

The name could be an unqualified name or a qualified name.

[expr.prim.id.unqual] p3 says

The result is the entity denoted by the unqualified-id ([basic.lookup.unqual]).

[qualified-id] p5 says

The result of a qualified-id Q is the entity it denotes ([basic.lookup.qual]).

[qualified-id] p5 might be clearer after adopting https://github.com/cplusplus/draft/issues/5346


I think once we determine that the "verb" X is what we want to pick for glvalue. we might use it in [expr.prim.id.unqual] and [qualified-id] p5 to specify what entity is Xed by unqualified-id or qualified-id when they are lvalue.

jensmaurer commented 2 years ago

The problem is that we use qualified-id and unqualified-id both for the expression / glvalue sense (which object are we talking about?) and in the identifier sense (which variable or data member are we talking about?) Those two meanings need to get a clear divorce, and the right approach is to move the variable / data member interpretation into [basic], and only leave the glvalue / expression interpretation in [expr].

xmh0511 commented 2 years ago

The problem is that we use qualified-id and unqualified-id both for the expression / glvalue sense (which object are we talking about?) and in the identifier sense (which variable or data member are we talking about?)

IIUC, do you mean that the name of a variable or data member can be associated with several objects? I want to divorce objects from variables. "variable" should have a pure meaning that its name could be used to refer to (conceptually) objects or references as determined by the declaration. For the problem that which object is designated/referred to by the name, I think it is determined by the evaluation of the glvalue.


In the current, the entity is an object, function, or something else specified in [basic.pre].

The result is the entity denoted by the unqualified-id ([basic.lookup.unqual]).

I construe this rule as that the name is used to denote (conceptually)objects rather than the concrete object. Because [basic.lookup] only associates the name with the found declaration, it cannot determine which object the name refers to. This part has been discussed in https://github.com/cplusplus/draft/issues/5346#issuecomment-1073921989

jensmaurer commented 2 years ago

do you mean that the name of a variable or data member can be associated with several objects?

Yes. Think about a local variable in a recursive function: you get a different object for each invocation.

xmh0511 commented 2 years ago

do you mean that the name of a variable or data member can be associated with several objects?

Yes. Think about a local variable in a recursive function: you get a different object for each invocation.

The problem coincidently falls into the discussion about variables in https://github.com/cplusplus/draft/issues/5346. We want "variable" to be an entity(object is not an entity), then the name denotes the "variable", as @opensdh said in https://github.com/cplusplus/draft/issues/5346#issuecomment-1073921989. The "reference" should also have the same problem(per thread or in a recursive function). We might consider "use a consistent verb" as the primary concern in this issue.