<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 537</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="537"></A><H4>537.
  
Definition of &#8220;signature&#8221;
</H4>
<B>Section: </B>Clause 3&#160; [<A href="https://wg21.link/intro.defs">intro.defs</A>]
 &#160;&#160;&#160;

 <B>Status: </B>CD1
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>12 October 2005<BR>


<P>[Voted into WP at April, 2007 meeting.]</P>



<P>The standard defines &#8220;signature&#8221; in two places:
Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] and 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
paragraphs 3-4.  The former seems to be meant as a formal definition
(I think it's the only place covering the nontemplate case), yet it
lacks some bits mentioned in the latter (specifically, the notion of a
&#8220;signature of a function template,&#8221; which is part of every
signature of the associated function template specializations).</P>

<P>Also, I think the Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] words &#8220;the
information about a function that participates in overload
resolution&#8221; isn't quite right either.  Perhaps, &#8220;the
information about a function that distinguishes it in a set of
overloaded functions?&#8221;</P>

<P>
<U>Eric Gufford</U>:</P>

<P>In Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] the definition states that
&#8220;Function signatures do not include return type, because that
does not participate in overload resolution,&#8221; while 13.7.7.2 [<A href="https://wg21.link/temp.over.link#4">temp.over.link</A>] paragraph 4 states &#8220;The signature of a
function template consists of its function signature, its return type
and its template parameter list.&#8221; This seems inconsistent and
potentially confusing. It also seems to imply that two identical
function templates with different return types are distinct
signatures, which is in direct violation of 12.2 [<A href="https://wg21.link/over.match">over.match</A>]. 13.7.7.2 [<A href="https://wg21.link/temp.over.link#4">temp.over.link</A>] paragraph 4 should be
amended to include verbiage relating to overload resolution.</P>

<P>Either return types are included in function signatures, or they're
not, across the board. IMHO, they should be included as they are an
integral part of the function declaration/definition irrespective of
overloads.  Then verbiage should be added about overload resolution to
distinguish between signatures and overload rules. This would help
clarify things, as it is commonly understood that overload
resolution is based on function signature.</P>

<P>In short, the term &#8220;function signature&#8221; should be made
consistent, and removed from its (implicit, explicit or otherwise)
linkage to overload resolution as it is commonly understood.</P>

<P>
<U>James Widman</U>: </P>

<P>The problem is that (a) if you say the return type is part of the
signature of a non-template function, then you have overloading but
not overload resolution on return types (i.e., what we have now with
function templates).  I don't think anyone wants to make the language
uglier in that way.   And (b) if you say that the return type is not
part of the signature of a function template, you will break code.
Given those alternatives, it's probably best to maintain the status
quo (which the implementors appear to have rendered faithfully).
</P>

<P><B>Proposed resolution (September, 2006):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="357.html">issue 357</A>.</P>

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