<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"><head>
<title>Nameless parameters and unutterable specializations</title>

<style type="text/css">/*<![CDATA[*/
body { color: #000000; background-color: #FFFFFF; max-width: 40em; }
del, .del { text-decoration: line-through; color: #8B0040; }
ins, .ins { text-decoration: underline; color: #005100; }

p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
  border: 1px solid #E1E28E; }

p.function { }
.attribute { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;
  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std, ul.std { color: #000000; background-color: #F1F1F1;
  border: 1px solid #D1D1D1;
  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.std del, blockquote.std .del, ul.std del, ul.std .del { text-decoration: line-through;
  color: #000000; background-color: #FFEBFF;
  border: 1px solid #ECD7EC; }
blockquote.std ins, blockquote.std .ins, ul.std ins, ul.std .ins { text-decoration: underline;
  color: #000000; background-color: #C8FFC8; }
blockquote.stddel { text-decoration: line-through;
  color: #000000; background-color: #FFEBFF;
  border: 1px solid #ECD7EC;
  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stdins { text-decoration: underline;
  color: #000000; background-color: #C8FFC8;
  border: 1px solid #B3EBB3;
  padding-left: 0.5em; padding-right: 0.5em; }

table { border: 1px solid black; border-spacing: 0px;
  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }
td { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }

table.table { border-spacing: 2px; border-collapse: separate; }
.table * th, .table * td { border: 1px solid black; }

table.frontmatter { border: 0; border-spacing: 0px; border-collapse: collapse; margin: 0; width: 619px; }
.frontmatter * td, .frontmatter * th { padding: 0px; }
.frontmatter * th { font-weight: inherit; text-align: left; vertical-align: top; }

ul.dash { list-style-type: none; }
ul.dash li:before { content: '\2014'; margin-left: -1em }

span.highlight { background-color: #7FDFFF }

.nowrap { white-space: nowrap; }
/*]]>*/
</style>

<script type="text/javascript" src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"></script>
</head>

<body>
<h1>Nameless parameters and unutterable specializations</h1>
<table class="frontmatter"><tbody>
    <tr>
        <th>Document number:</th>
        <td>P0736R0</td>
    </tr>
    <tr>
        <th>Date:</th>
        <td>2018-02-12</td>
    </tr>
    <tr>
        <th>Project:</th>
        <td>ISO/IEC JTC 1/SC 22/WG 21/C++</td>
    </tr>
    <tr>
        <th>Working Group:</th>
        <td>Evolution</td>
    </tr>
    <tr>
        <th>Revises:</th>
        <td><i>None</i></td>
    </tr>
    <tr>
        <th>Reply-to:</th>
        <td><span class="nowrap">Hubert S.K. Tong</span> &lt;<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>&gt;</td>
    </tr>
</tbody></table>

<h2>Issue/Background</h2>

<p>When an expression is part of a signature for a function template, whether expressions are equivalent for the purposes of resolving declarations of the same entity to each other is defined by [temp.over.link].
This definition in turn relies on the form of the expression in the style of the one-definition rule ([basic.def.odr]).</p>

<p>Unfortunately, it is not specified what form an expression takes when template parameters are substituted with their corresponding arguments.
Indeed, with the addition of <i>requires-clause</i>s, substitution might not occur in certain subexpressions.
This frustrates the ability to form redeclarations in contexts where certain template parameters have no name, such as when an enclosing template is explicitly specialized.
Redeclarations in such contexts also obfuscate the relationship between declarations expressed in terms of the primary template and declarations expressed with reference to specializations.</p>


<h2>Current implementation behaviour</h2>

<p>Even without the addition of Concepts, it is possible to encounter the problem of lacking a suitable way to form equivalent corresponding expressions in redeclarations.</p>

<p>For example, given:</p>
<pre class="prettyprint lang-cpp"
>template &lt;unsigned N&gt;
struct TA {
  template &lt;unsigned M&gt;
  void f(unsigned (*)[N + M]);
};</pre>

<p>An attempt to produce an explicit specialization of <code>f</code> for <code>TA&lt;0&gt;</code> might yield:</p>
<pre class="prettyprint lang-cpp"
>template &lt;&gt;
template &lt;unsigned M&gt;
void TA&lt;0&gt;::f(unsigned (*)[0u + M]);</pre>

<p>Indeed, it happens to work with both GCC and Clang.
Unfortunately, not all literal types can necessarily have their values expressed as integer literals (<code>short</code> comes to mind).
In any case, it only happens to work and may stop working at any time.
GCC (at least as late as version 7.2 from August 2017) would have accepted <code>0</code> in place of <code>0u</code> despite the type mismatch
(so the <code>short</code> conundrum was somewhat sidestepped), but no longer does so.</p>

<p>Now with the addition of Concepts, an additional complication appears.</p>
<p>Given:</p>
<pre class="prettyprint lang-cpp"
>template &lt;typename T&gt;
struct TB {
  template &lt;typename U&gt;
  void f() requires U::value &amp;&amp; T::value;
};</pre>

<p>A similar approach to forming the explicit specialization of <code>f</code> for <code>TB&lt;int&gt;</code> would create the unutterable <code>int::value</code>.
I am not aware of any version of the Concepts implementation that does not reject the utterance of <code>int::value</code>.</p>


<h2>Possible solutions</h2>

<p>It is the hope of the author that either
a solution is adopted to ease the formation of related declarations or
the effective inability to produce truly equivalent expressions in said contexts is made clear through examples to be incorporated into the Standard.</p>

<p>In the pursuit of a solution, syntax to allow binding of a name for specialized template arguments of the primary template could be explored.</p>
<p>In the context of the above cases, such syntax may look like this:</p>
<pre class="prettyprint lang-cpp"
>template &lt;&gt;
template &lt;unsigned M&gt;
void TA&lt;N: 0&gt;::f(unsigned (*)[N + M]);

template &lt;&gt;
template &lt;typename U&gt;
void TB&lt;T: int&gt;::f() requires U::value &amp;&amp; T::value;</pre>

<p>Notice that in the latter case, <code>T</code> would need to be treated as dependent.</p>

<p>Such a binding could also allow for partial specializations to have constraints expressed in terms of the parameters to the primary template; however, an extra complication is needed to introduce the names before their use:</p>
<pre class="prettyprint lang-cpp"
>template &lt;typename T, typename U&gt;
struct A;

[T, U] template &lt;typename TT, typename UU&gt;
requires C&lt;T, U&gt;
struct A&lt;T: TT *, U: UU&gt; { };

[T, U] template &lt;typename TT, typename UU&gt;
requires C&lt;T, U&gt; &amp;&amp; C1&lt;T&gt;
struct A&lt;T: TT, U: UU *&gt; { };
</pre>

<p>Notice that without the binding, the intended subsumption of <code>C&lt;T, U&gt;</code> in the first specialization by the <i>requires-clause</i> of the second would be muddied.</p>

<p><i>Thus we speak the unutterable and name the nameless.</i></p>
</body>
</html>
