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

[dcl.type.decltype] p1 What is the entity named by E when E is a class member access #5342

Open
xmh0511 opened this issue Mar 15, 2022 · 4 comments
Open

[dcl.type.decltype] p1 What is the entity named by E when E is a class member access #5342

xmh0511 opened this issue Mar 15, 2022 · 4 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Mar 15, 2022 •
edited

[dcl.type.decltype] p1.3 states:

For an expression E, the type denoted by decltype(E) is defined as follows:

  • [...]
  • otherwise, if E is an unparenthesized id-expression or an unparenthesized class member access ([expr.ref]), decltype(E) is the type of the entity named by E. If there is no such entity, the program is ill-formed;

This sentence is obscure and subtle when E is a class member access. Consider this example:

struct C{
  int v;
};
C const obj{};  
decltype(obj.v) i;  // the type of i is `int` rather than `const int`. 
i = 0; // ok

We seem to never clearly specify what the entity named by a class member access is. [basic.pre] p3 just states that:

An entity is a value, object, reference, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.

In this case, we can say the class member access E names the subobject associated with C::v or just names the class member C::v, they all be called entity. They have a huge different type due to the type of object expression(int vs. int const). It is not clear which is the correct interpretation, at least we never explicitly specify them in [expr.ref].

[expr.ref] p6 just specifies that

If E2 is a non-static data member..., the expression designates the corresponding member subobject of the object designated by the first expression.

Since [dcl.type.decltype] p1.3 references [expr.ref], we should clearly specify what the entity named by E1.E2 is, in [expr.ref].

Moreover, denote/named/designate should be explicitly defined if using them with the concrete component would have a different meaning.
@jensmaurer
Copy link
Member

Maybe it's easier to replace "the type of the entity named by E" with "the declared type of the class member named by E", which I think also resolves the problem.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Mar 17, 2022 •
edited

Maybe it's easier to replace "the type of the entity named by E" with "the declared type of the class member named by E", which I think also resolves the problem.

That may more directly get what type the decltype(E) denotes, but the original bullet may need to be decomposed into two bullets: one is for id-expression, another is for class member access.

And for class member access case, it might be more clear as the following:

the declared type of the class member named denoted by id-expression of E(i.e. class member access expression).

"denote" is defined

The result is the entity denoted by the unqualified-id

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

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

@languagelawyer
Copy link
Contributor

[basic.pre] p3 just states that:

An entity is a value, object, reference, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.

A friendly reminder that [basic.pre]/3 is defective and should be

An entity is a value, object, reference variable, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.

(Not a final state, maybe template-parameter-object should also be here and bit-field need not; class-member should be made non-static, because a static one is a variable)

[dcl.type.decltype]:

If there is no such entity, the program is ill-formed

Is this necessary? I think there already wording saying that if nothing is found by lookup the program is ill-formed.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Mar 17, 2022

If there is no such entity, the program is ill-formed

I think so. It is a bit redundant that could be regulated by name lookup.

For the radical use of "variable", I think we need to first clarify what is the variable. Specifically, what is the declaration of an object or reference, see #4749

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

No branches or pull requests
3 participants
@xmh0511 @jensmaurer @languagelawyer