[basic.def.odr] p15 Whether the specified behavior is prior to the analysis of the requirements

[xmh0511]

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

[basic.def.odr] p14 says

Given such an item, for all definitions of D, or, if D is an unnamed enumeration, for all definitions of D that are reachable at any given program point, the following requirements shall be satisfied.

• [...]
• In each such definition, corresponding names, looked up according to [basic.lookup], shall refer to the same entity, after overload resolution ([over.match]) and after matching of partial template specialization ([temp.over]), except that a name can refer to

[basic.def.odr] p15 says

For each such entity and for D itself, the behavior is as if there is a single entity with a single definition, including in the application of these requirements to other entities.

// TU A
inline void fun(){
   int a = 0;
   auto b = a;
}
// TU B
inline void fun(){
   int a = 0;
   auto b = a;
}

The issue is, whether the name a refers to the same entity or not. [basic.link] cannot apply to this case because a does not have a linkage. Unlike C++17 standard

in each definition of D, corresponding names, looked up according to [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity

So, the issue is, which opinion is the intent

1. we should first assume these definitions have the behavior specified in [basic.def.odr] p15 prior to we start to check whether these definitions satisfy the requirements in the list
2. only these definitions that satisfy the requirements will have the behavior specified in [basic.def.odr] p15.

Anyway, we cannot check whether the a in the two definitions refer to the same entity or not if the intent is the opinion 2. However, the order of the rules and the wording does lead us to read out opinion 2.

If the intent is opinion 1, that means, the requirement always be satisfied by D because it is assumed to have a single definition. This will not make sense. So, both opinions have their issues for the entity defined in D and D.

[frederick-vs-ja]

in each definition of D, corresponding names, looked up according to [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity

The wording here is changed by CWG2300. We may need to carefully make clarification to avoid regression.

[xmh0511]

The wording here is changed by CWG2300. We may need to carefully make clarification to avoid regression.

I didn't suggest to revert the old wording. We agree that we should clarify the issues mentioned above based on the current wording.

[jensmaurer]

I think the example in p16 makes it clear how to read the rules. In this case, the "same entity" question relates to the closure type, as opposed to a local variable, but it's the same question.

Put differently, p14.5 and p15 interact to make sure we get the "single entity" interpretation recursively, where needed.

Given the example and absent any demonstrated implementation divergence and absent a specific suggestion how to improve the wording, I don't think I'll spend CWG bandwidth on this.

[xmh0511]

Given the example and absent any demonstrated implementation divergence and absent a specific suggestion how to improve the wording

These preconditions that we assume to be true should be placed prior to the requirements we specified in the list. That is, we should separate p15 into two parts.

Given such an item, for all definitions of D, or, if D is an unnamed enumeration, for all definitions of D that are reachable at any given program point, under the assumption that the corresponding entities defined within each definition of D are as if they are the same entity with a single definition, the following requirements shall be satisfied.

Then, in p15, we say

For such D, the behavior is as if there is a single entity with a single definition.