<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 448</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="448"></A><H4>448.
  
Set of template functions in call with dependent explicit argument
</H4>
<B>Section: </B>13.8.2&#160; [<A href="https://wg21.link/temp.local">temp.local</A>]
 &#160;&#160;&#160;

 <B>Status: </B>C++11
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>4 Jan 2004<BR>


<P>[Voted into WP at August, 2010 meeting.]</P>

<P>Is this program valid?</P>
<PRE>
  template &lt;typename T&gt; int g(int);
  class h{};
  template &lt;typename T&gt; int l(){h j; return g&lt;T&gt;(j);}
  template &lt;typename T&gt; int g(const h&amp;);
  class j{};
  int jj(){return l&lt;j&gt;();}
</PRE>
<P>The key issue is when "g" is looked up, i.e., whether both overloaded
template "g" functions are available at the call site or only the
first.  Clearly, the entire postfix-expression "g&lt;T&gt;(j)" is dependent,
but when is the set of available template functions determined?</P>

<P>For consistency with the rules about when the set of available
overloads is determined when calling a function given by an
unqualified-id, I would think that we should postpone determining the
set of template functions if (and only if) any of the explicit
template arguments are dependent.</P>

<P>
<U>John Spicer:</U>
I agree that there should be a core issue for this.  The definition of
"dependent name" (13.8.3 [<A href="https://wg21.link/temp.dep#1">temp.dep</A>] paragraph 1)
should probably be modified to cover this case.  It
currently only handles cases where the function name is a simple
identifier.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>A related issue is a call with a qualified name and dependent
arguments, e.g., <TT>x::y(depa, depb)</TT>.</P>

<P><B>Proposed resolution (June, 2010):</B></P>

<OL>
<LI><P>Change 13.8.3 [<A href="https://wg21.link/temp.dep#1">temp.dep</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...In an expression of the form:</P>

<UL>
<I>postfix-expression</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB></I> <TT>)</TT>
</UL>

<P>where the <I>postfix-expression</I> is an
<DEL><I>unqualified-id</I></DEL>
<INS><I>id-expression</I></INS>, the
<DEL><I>unqualified-id</I></DEL>
<INS><I>id-expression</I></INS> denotes a <I>dependent
name</I> if <DEL>and only if</DEL> any of the expressions in
the <I>expression-list</I> is a type-dependent expression
(13.8.3.3 [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]) <INS>or if the
<I>unqualified-id</I> of the <I>id-expression</I> is a
<I>template-id</I> in which any of the template arguments depends
on a template parameter</INS>.  If an operand of an operator is a
type-dependent expression, the operator also denotes a dependent
name.  Such names are unbound and are looked up at the point of
the template instantiation (13.8.4.1 [<A href="https://wg21.link/temp.point">temp.point</A>]) in
both the context of the template definition and the context of
the point of instantiation.</P>

</BLOCKQUOTE>

<LI><P>Change 13.8.4.2 [<A href="https://wg21.link/temp.dep.candidate#1">temp.dep.candidate</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>For a function call that depends on a template parameter, <DEL>if
the function name is an <I>unqualified-id</I>
or if the function is called using operator
notation,</DEL> the candidate functions are found using the usual
lookup rules (6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>], 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]<INS>, 6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]</INS>) except
that:</P>

<UL>
<LI><P>For the part of the lookup using unqualified name
lookup (6.5.3 [<A href="https://wg21.link/basic.lookup.unqual">basic.lookup.unqual</A>]) <INS>or qualified name
lookup (6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>])</INS>, only function
declarations from the template definition context are
found.</P></LI>

<LI><P>For the part of the lookup using associated
namespaces (6.5.4 [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]), only function
declarations found in either the template definition context
or the template instantiation context are found.</P></LI>

</UL>

<P>If <INS>the function name is an <I>unqualified-id</I>
and</INS> the call would be ill-formed or would find a better
match had the lookup within the associated namespaces considered
all the function declarations with external linkage introduced in
those namespaces in all translation units, not just considering
those declarations found in the template definition and template
instantiation contexts, then the program has undefined
behavior.</P>

</BLOCKQUOTE>

</OL>

<BR><BR>
</BODY>
</HTML>
