[dcl.meaning.general] Improve clarity of presentation #4611
Conversation
of name matching more readable. Avoid shadowing the name S with a different meaning in the same paragraph by moving the block-scope extern handling to its own paragraph.
looked up" wording earlier and explicitly call out the special cases.
| are considered when identifying | ||
| any function template specialization being declared\iref{temp.deduct.decl}. | ||
| any function or variable template specialization |
There was a problem hiding this comment.
@opensdh Was the different treatment of function and variable template specializations intended?
There was a problem hiding this comment.
It was (although that doesn't guarantee that it's good to do so!). The idea is that we do ordinary lookup for the name before the < (and for an explicit specialization/instantiation without an explicit template argument list, for consistency): if we find a variable template, it must be the unique lookup result, so there isn't any reason to disqualify that one result because of nominability. I think we did talk about this in the review, but I can't find the minutes for it.
| If it declares a class member, | ||
| the terminal name of the \grammarterm{declarator-id} is not looked up; | ||
| otherwise, only those lookup results that are nominable in $S$ | ||
| If such a \grammarterm{declarator} does not declare a class member, |
There was a problem hiding this comment.
@opensdh I tried to figure out why we're treating class members differently from non-class-members here and didn't succeed. Perhaps an example would help? I'm also not sure how we're supposed to handle an explicit specialization of a class member template without performing name lookup. Was the intent here instead that if the specialization or instantiation is for a non-template member of a class template specialization, no lookup is performed?
There was a problem hiding this comment.
I think that you're right: we do have to do the lookup for the same reason that we have to do it when encountering template<> my_namespace::my_class< since it might continue int>::sub_template<int> { or just int> {. You're probably right about the intent too, but I'm less clear on that at the moment. (My plan is to, tomorrow, look at your wording here and see if I see any problems with it of a similar sort; if not, it stands to reason that it reflects the intent better.)
|
I will get to this, but I'm out for about a week starting now (and expect to be at least as busy with Real Work when I return as I am now). |
| the declaration shall correspond to a declaration | ||
| that inhabits the innermost block scope. | ||
| \end{itemize} | ||
|
|
||
| \pnum | ||
| Otherwise: | ||
| If the declaration is not a friend declaration: |
There was a problem hiding this comment.
As this is exhaustive together with the previous paragraph, I'd prefer to use one of our formulations that indicates that: perhaps
Otherwise, the declaration is not a friend declaration:
or
Otherwise (for a non-friend declaration):
| If the \grammarterm{declarator} declares | ||
| an explicit instantiation or a partial or explicit specialization, | ||
| the \grammarterm{declarator} does not bind a name. |
There was a problem hiding this comment.
This is actually redundant: such declarations do not introduce names ([temp.explicit]/5, [temp.expl.spec]/4, and [temp.spec.partial.general]/7), so [basic.scope.scope]/2.5 ignores them already. This is relevant because it is an opportunity to merge into the next sentence (once we're sure exactly what we mean it to mean).
jensmaurer
added
the
changes requested
|
@zygoloid , looks like there are some changes still open. |
wg21bot
added
the
needs rebase
[dcl.meaning.general] is hard to read currently, mostly due to a dense nesting of "if" / "otherwise" clauses where it's not always clear which wording is in the scope of which "if"s, and what each "otherwise" binds to. This PR attempts to clean this up a bit.
In passing, I also fixed an issue where we use the same name
Sfor two different purposes in the same scope, and front-loaded the "declarator-id is normally not looked up" rule so that the special cases where lookup does happen are more obvious.@opensdh Your review in particular would be appreciated.