This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Voted into WP at August, 2010 meeting.]
Is this program valid?
template <typename T> int g(int); class h{}; template <typename T> int l(){h j; return g<T>(j);} template <typename T> int g(const h&); class j{}; int jj(){return l<j>();}The key issue is when "g" is looked up, i.e., whether both overloadedtemplate "g" functions are available at the call site or only thefirst. Clearly, the entire postfix-expression "g<T>(j)" is dependent,but when is the set of available template functions determined?
For consistency with the rules about when the set of availableoverloads is determined when calling a function given by anunqualified-id, I would think that we should postpone determining theset of template functions if (and only if) any of the explicittemplate arguments are dependent.
John Spicer:I agree that there should be a core issue for this. The definition of"dependent name" (13.8.3 [temp.dep] paragraph 1)should probably be modified to cover this case. Itcurrently only handles cases where the function name is a simpleidentifier.
Notes from the March 2004 meeting:
A related issue is a call with a qualified name and dependentarguments, e.g.,x::y(depa, depb).
Proposed resolution (June, 2010):
Change 13.8.3 [temp.dep] paragraph 1 as follows:
...In an expression of the form:
postfix-expression(expression-listopt)
where thepostfix-expression is an
unqualified-idid-expression, theunqualified-idid-expression denotes adependentname ifand only ifany of the expressions intheexpression-list is a type-dependent expression(13.8.3.3 [temp.dep.expr])or if theunqualified-id of theid-expression is atemplate-id in which any of the template arguments dependson a template parameter. If an operand of an operator is atype-dependent expression, the operator also denotes a dependentname. Such names are unbound and are looked up at the point ofthe template instantiation (13.8.4.1 [temp.point]) inboth the context of the template definition and the context ofthe point of instantiation.
Change 13.8.4.2 [temp.dep.candidate] paragraph 1 as follows:
For a function call that depends on a template parameter,
ifthe function name is anunqualified-idor if the function is called using operatornotation,the candidate functions are found using the usuallookup rules (6.5.3 [basic.lookup.unqual], 6.5.4 [basic.lookup.argdep], 6.5.5 [basic.lookup.qual]) exceptthat:
For the part of the lookup using unqualified namelookup (6.5.3 [basic.lookup.unqual])or qualified namelookup (6.5.5 [basic.lookup.qual]), only functiondeclarations from the template definition context arefound.
For the part of the lookup using associatednamespaces (6.5.4 [basic.lookup.argdep]), only functiondeclarations found in either the template definition contextor the template instantiation context are found.
Ifthe function name is anunqualified-idand the call would be ill-formed or would find a bettermatch had the lookup within the associated namespaces consideredall the function declarations with external linkage introduced inthose namespaces in all translation units, not just consideringthose declarations found in the template definition and templateinstantiation contexts, then the program has undefinedbehavior.