<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<style>
body {
	font-family: sans-serif;
	background-color: gray;
	margin: 2pc 0;
	line-height: 140%;
	font-size: small;
}
#document {
	background-color: white;
	color: black;
	padding: 2pc;
	box-shadow: 0 0 40px black;
	max-width: 56pc;
	margin-left: auto;
	margin-right: auto;
}
code {
	color: #900;
}
p {
	margin-left: 4pc;
	margin-right: 3pc;
}
ul, ol {
	margin-left: 4pc;
}
li {
	margin-bottom: 3pt;
}
h2 {
	border-top: 1px solid lightgray;
	padding-top: 1.5pc;
	margin-top: 1.5pc;
}
h3 {
	margin-left: 2pc;
}
h4 {
	margin-left: 4pc;
}
pre {
	margin-left: 3.75pc;
	margin-right: 3pc;
	background: #eee;
	padding: 3pt;
}
</style>
<head>
<body>
<div id="document">
<h1 id="fixed-size-parameter-packs">Fixed Size Parameter Packs</h1>
<p>ISO/IEC JTC1 SC22 WG21 N4072 — 2014-05-26</p>
<p><em>M. Bos &lt;m-ou.se@m-ou.se&gt;</em></p>
<h2 id="summary">Summary</h2>
<p>This document proposes an extension to the <code>T...</code>-notation for parameter packs: <code>T...[N]</code> to give the pack a fixed size. (This might sound close to useless at first, but this document should hopefully convince you otherwise.) This allows for elegant and readable solutions for problems that used to require a lot of confusing boiler plate code, such as taking a variable number of parameters of the same type.</p>
<h2 id="the-proposed-idea">The Proposed Idea</h2>
<p>In both template parameter lists and function parameter lists, <code>T...[N] p</code> would make <code>p</code> a parameter pack of exactly <code>N</code> <code>T</code>s. <code>N</code> must be a constant expression.</p>
<p>So, <code>void foo(int...[3] args)</code> would make <code>args</code> a pack of three integers, such that <code>foo</code> can be called as <code>foo(1,2,3)</code>. Similarly, <code>template&lt;typename...[2] Args&gt; void foo(Args... args)</code> would make <code>Args</code> a pack of two typenames (and therefore <code>args</code> a pack of two objects of those two types).</p>
<h2 id="use-cases-and-examples">Use Cases and Examples</h2>
<p>This section describes a few use cases. All first describe the scenario, then give a solution with what's currently possible with C++14, and then give a solution using the proposed idea.</p>
<p>The first two/three are the most important and interesting use cases.</p>
<h3 id="a-constant-dependent-number-of-parameters">1) A constant (dependent) number of parameters</h3>
<h4 id="scenario">Scenario</h4>
<p>Imagine we're making a class <code>my_vector3</code>, which represents a three-dimensional mathematical vector of integers. It has a constructor <code>my_vector3(int, int, int)</code> that takes exactly three integers, as you'd probably expect of such a class:</p>
<pre><code>struct my_vector3 {
    // ...
    my_vector3(int x, int y, int z)
        : values{x, y, z} {}
};</code></pre>
<p>Now we want to turn this into a class template <code>my_vector&lt;N&gt;</code>, such that the number of dimensions is not fixed to three. Logically, it should have a constructor that takes exactly <code>N</code> integers, but how would we do that?</p>
<h4 id="current-solution">Current solution</h4>
<p>This is probably the closest we can get with C++14:</p>
<pre><code>// Helper template gen_tuple:
// gen_tuple&lt;3, int&gt;::type becomes std::tuple&lt;int, int, int&gt;, etc.

template&lt;unsigned int N, typename T&gt; struct gen_tuple {
    using type = decltype(
        std::tuple_cat(
            std::declval&lt;std::tuple&lt;T&gt;&gt;(),
            std::declval&lt;typename gen_tuple&lt;N-1, T&gt;::type&gt;()
        )
    );
};

template&lt;typename T&gt; struct gen_tuple&lt;0, T&gt; {
    using type = std::tuple&lt;&gt;;
};

namespace impl {
    // This template will only ever be instantiated with an std::tuple of ints.
    template&lt;typename&gt; struct my_vector;
    template&lt;typename... ints&gt; struct my_vector&lt;std::tuple&lt;ints...&gt;&gt; {
        static constexpr unsigned int N = sizeof...(ints);
        // ...
        my_vector(ints... v) : values{v...} {}
    };
}

template&lt;unsigned int N&gt;
using my_vector = impl::my_vector&lt;typename gen_tuple&lt;N, int&gt;::type&gt;;</code></pre>
<p>Not only does this take a lot of code, defining <code>impl::my_vector</code> this way is confusing and error prone. (Also, note that using this solution, <code>N</code> can not be inferred when calling something like <code>template&lt;unsigned int N&gt; void foo(my_vector&lt;N&gt;)</code>. However, this can be fixed by changing the alias template for a class template that has <code>impl::my_vector</code> as a base and inherits the constructors.)</p>
<h4 id="new-solution">New solution</h4>
<p>With the 'fixed size parameter packs' feature this document proposes, the <code>my_vector</code> template can simply be written as:</p>
<pre><code>template&lt;unsigned int N&gt;
struct my_vector {
    // ...
    my_vector(int...[N] v) : values{v...} {}
};</code></pre>
<p>Beautiful!</p>
<h3 id="a-variable-number-of-parameters-of-a-specific-type">2) A variable number of parameters of a specific type</h3>
<h4 id="scenario-1">Scenario</h4>
<p>Let's say we have a function <code>void foo3(int, int, int)</code>, that does something with three integers. However, instead of also writing a <code>foo4</code> to do it with four integers, we'd like to turn it into a template such that we have <code>foo&lt;N&gt;</code> for any <code>N</code>.</p>
<h4 id="current-solution-1">Current solution</h4>
<pre><code>template&lt;bool...&gt; constexpr bool all = true;
template&lt;bool head, bool... tail&gt; constexpr bool all&lt;head, tail...&gt; = head &amp;&amp; all&lt;tail...&gt;;

template&lt;
    typename... T,
    typename = std::enable_if_t&lt;
        all&lt;std::is_convertible&lt;T, int&gt;::value...&gt;
    &gt;
&gt;
void foo(T&amp;&amp;...);</code></pre>
<p>A few notes:</p>
<ul>
<li><code>foo3(1, 2u, 3l)</code> would convert the <code>2u</code> and <code>3l</code> to <code>int</code>s before the function call, <code>foo(1, 2u, 3l)</code> would convert them later, inside the function. (Which doesn't really matter for integral types, but for other types it could be more significant.)</li>
<li>Because of this, each of the following instantiate the function template again with different <code>T...</code>: <code>foo(1, 2, 3)</code>, <code>foo(1u, 2l, 3)</code>, etc.</li>
<li>Errors can be confusing when calling <code>foo</code> with wrong parameters.</li>
</ul>
<p>So, this requires some boiler plate code, it is not very readable, and although it comes close, it is not exactly what we wanted.</p>
<h4 id="new-solution-1">New solution</h4>
<pre><code>template&lt;unsigned int N&gt; void foo(int...[N] v);</code></pre>
<p>Beautiful!</p>
<h4 id="discussion">Discussion</h4>
<p>See <a href="#discussion-of-use-case-2">Discussion of Use Case 2</a> for a small discussion about this use case.</p>
<h3 id="a-variable-number-of-parameters-of-the-same-type">3) A variable number of parameters of the same type</h3>
<h4 id="scenario-2">Scenario</h4>
<p>Suppose we have a class template <code>iterleaving_iterator&lt;ForwardIterator, N&gt;</code> which is an iterator that interleaves <code>N</code> streams from iterators of the type <code>ForwardIterator</code>. (Such that a <code>interleaving_iterator&lt;vector&lt;int&gt;::iterator, 3&gt;</code> allows us to iterate over <code>{1,2,3}</code>, <code>{10,20,30}</code>, and <code>{100,200,300}</code> at once as <code>{1,10,100,2,20,200,3,30,300}</code>.)</p>
<p>Now, we want a function <code>interleave</code> that takes itererators and returns such an <code>interleaving_iterator</code>, with both template parameters automatically deduced. (Such that <code>auto it = interleave(a.begin(), b.begin(), c.begin());</code> works.)</p>
<h4 id="current-solution-2">Current solution</h4>
<pre><code>template&lt;typename... T&gt; struct all_the_same {};
template&lt;typename T&gt; struct all_the_same&lt;T&gt; {
    using type = T;
};
template&lt;typename Head, typename... Tail&gt; struct all_the_same&lt;Head, Head, Tail...&gt;
    : all_the_same&lt;Head, Tail...&gt; {};

template&lt;typename... T&gt;
interleaving_iterator&lt;typename all_the_same&lt;T&gt;::type, sizeof...(T)&gt; interleave(T... it) {
    return { it... };
}</code></pre>
<h4 id="new-solution-2">New solution</h4>
<pre><code>template&lt;typename Iterator, unsigned int N&gt;
interleaving_iterator&lt;Iterator, N&gt; interleave(Iterator...[N] it) {
    return { it... };
}</code></pre>
<p>Other than that this code is much easier to write and read, the error message a user gets when accidentally calling <code>interleave</code> with arguments of different types can just explain the user that <code>interleave</code> expects all <code>it</code> arguments to be of the same type.</p>
<h3 id="a-fixed-number-of-parameters-of-any-mixed-types">4) A fixed number of parameters (of any mixed types)</h3>
<h4 id="scenario-3">Scenario</h4>
<p>With <code>template&lt;unsigned int N&gt; struct foo</code>, add a member function <code>foo&lt;N&gt;::bar</code> taking exactly N parameters of any type.</p>
<h4 id="current-solution-3">Current solution</h4>
<pre><code>template&lt;unsigned int N&gt;
struct foo {
    template&lt;typename... T, typename = std::enable_if_t&lt;sizeof...(T) == N&gt;&gt; void bar(T... v);
};</code></pre>
<h4 id="new-solution-3">New solution</h4>
<pre><code>template&lt;unsigned int N&gt;
struct foo {
    template&lt;typename...[N] T&gt; void bar(T... v);
};</code></pre>
<h3 id="just-to-avoid-repetition">5) Just to avoid repetition</h3>
<p>And as a last example, the proposed feature could be used just to avoid repeating parameters:</p>
<h4 id="current-solution-4">Current solution</h4>
<pre><code>void foo(int x, int y, int z, int w) { do_magic(x, y, z, w); }

template&lt;typename A, typename B, typename C, typename D, typename E&gt;
void bar(A a, B b, C c, D d, E e);</code></pre>
<p>(Of course, <code>typename...</code> and <code>enable_if_t</code> with <code>sizeof...</code> could be used for <code>bar</code>, but that was already used in use case 4.)</p>
<h4 id="new-solution-4">New solution</h4>
<pre><code>void foo(int...[4] v) { do_magic(v...); }

template&lt;typename...[5] T&gt;
void bar(T... v);</code></pre>
<h2 id="discussion-of-use-case-2">Discussion of Use Case 2</h2>
<p>In C++, it's very easy to make a function that takes</p>
<ol style="list-style-type: decimal">
<li>two integers: <code>void foo(int, int);</code></li>
<li>two parameters of any type: <code>template&lt;typename A, typename B&gt; void foo(A, B);</code></li>
<li><em><s>any number of integers</s></em>.</li>
<li>any number of parameters of any type: <code>template&lt;typename... T&gt; void foo(T...);</code></li>
</ol>
<p>Unfortunately, option 3 would be useful but is missing. The only option now is to use option 4 combined with <code>enable_if</code> and <code>is_convertible</code>. (Imagine a world where option 1 doesn't exist, such that the only way is to use option 2 combined with <code>enable_if</code> and <code>is_convertible</code>.)</p>
<p>A suggestion I've often heard as a solution to this problem is this:</p>
<pre><code>void foo(int... a);</code></pre>
<p>(This could seem very logical, since the <code>...</code> here is used the same as in <code>template&lt;typename...&gt;</code>.)</p>
<p>Apart from that the syntax itself is a problem (since <code>void foo(int...)</code> is already a C <code>vararg</code> function), there's another problem: This defines a <em>template</em>, not just a function, without using the keyword <code>template</code>. From recent discussions about whether to allow <code>void foo(auto a)</code> or not to define a function template, this seems like a bad idea. So, we want to add the <code>template</code> keyword explicitly:</p>
<pre><code>template&lt;/* What do we put here? */&gt; void foo(int... a);</code></pre>
<p>The only difference between the instantiations of <code>foo</code> is the number of parameters, so it'd make sense to make this the template parameter:</p>
<pre><code>template&lt;unsigned int&gt; void foo(int... a);</code></pre>
<p>But we need to specify that this integer is the length of the pack. To do that, we would end up with something like:</p>
<pre><code>template&lt;unsigned int N&gt; void foo(int...[N] v);</code></pre>
<p>And this is exactly what this paper proposes.</p>
<h2 id="template-argument-deduction">Template Argument Deduction</h2>
<p>With <code>template&lt;typename T, unsigned int N&gt; void foo(T...[N]) {}</code>, <code>T</code> can be deduced for any <code>N &gt; 0</code> using the same rules as used for <code>template&lt;typename T&gt; void bar(T, T, T) {}</code>.</p>
<p>More interesingly, it is important that <code>N</code> can be deduced: <code>N</code> would be deducable if the parameter list ends with a fixed size parameter pack of size <code>N</code>. For example, in these cases template argument deduction would work:</p>
<pre><code>template&lt;unsigned int N&gt; void f(int...[N]) {}
f(1,2,3); // N is deduced as 3.</code></pre>
<p></p>

<pre><code>template&lt;unsigned int N&gt; void f(int, int...[N]) {}
f(1,2,3); // N is deduced as 2.</code></pre>
<p></p>

<pre><code>template&lt;unsigned int N, unsigned int M&gt; void f(int...[N], int...[M]) {}
f&lt;2&gt;(1,2,3); // M is deduced as 1. (N can&#39;t be deduced, but is given.)</code></pre>
<p>And it would work for none of these cases:</p>
<pre><code>template&lt;unsigned int N&gt; void f(int...[N], int) {}
f(1,2,3);</code></pre>
<p></p>

<pre><code>template&lt;unsigned int N&gt; void f(int...[N], int...[N]) {}
f(1,2,1,2);</code></pre>
<p></p>

<pre><code>template&lt;unsigned int N&gt; void f(int...[N*2]) {}
f(1,2,3,4);</code></pre>
<h2 id="technical-specification">Technical Specification</h2>
<p>TODO</p>
<p>(I could use some help here.)</p>
<h2 id="acknowledgements">Acknowledgements</h2>
<p>I want to thank the people on Freenode's ##C++ and cpp-proposals@isocpp.org I discussed this idea with. Also, thank you, Filip Roséen <em>&lt;filip.roseen@gmail.com&gt;</em>, for your helpful feedback and coming up with the C++14 solution for use case 1.</p>
<div style="text-align: center; border-top: 1px solid gray; margin-top: 4pc; padding-top: 0.5pc;">
N4072 — Fixed Size Parameter Packs — M. Bos <em>&lt;m-ou.se@m-ou.se&gt;</em>
</div>


</div>
</body>
