﻿<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<style type="text/css">
.comment { color: #999999; font-style: italic; }
.pre { color: #000099; }
.string { color: #009900; }
.char { color: #009900; }
.float { color: #996600; }
.int { color: #999900; }
.bool { color: #000000; font-weight: bold; }
.type { color: #FF6633; }
.flow { color: #FF0000; }
.keyword { color: #990000; }
.operator { color: #663300; font-weight: bold; }
.operator { color: #663300; font-weight: bold; }
pre.code {
    border: 2px solid #666;
    background-color: #F4F4F4;
    padding-left: 10px;
    padding-top: 0px;
}
code {
    border: 2px solid #d0d0d0;
    background-color: LightYellow;
    padding: 2px;
    padding-left: 10px;
    display:table;
    white-space:pre;
    margin:2px;
    margin-bottom:10px;
}
dt
{
    font-weight: bold;
}
    
.ins {
    background-color:#A0FFA0;
}

.del {
    background-color:#FFA0A0;
    text-decoration:line-through
}    
</style>
    <title>Tuple Tidbits</title>
</head>
<body>
N3404=12-0094<br />
    2012-09-22<br />
    Mike Spertus, 
    Symantec<br />
    <a href="mailto:mike_spertus@symantec.com"><tt>mike_spertus@symantec.com</tt></a><br/>
    <h1>Tuple Tidbits</h1>

    <h2>
        Overview</h2>
    <p>
        The purpose of this paper is to propose two extensions to <tt>tuple:</tt></p>
    <ol>
        <li>Following the suggestion in [<a href="#ref_1">1</a>], make <tt>tuple</tt>s addressable 
            by type as well as by index.</li>
        <li>Make <tt>tuple</tt> functorial in category-theoretical sense</li>
    </ol>
    <p>
        Both of these are implemented</p>
    <h2>
        Addressing <tt>tuple</tt>s by type</h2>
    <p>
        This is an idea 
        is inspired by Alexandrescu&#39;s <em>Modern C++ Design</em> [<a href="#ref_1">1</a>] 
        <tt>tuple</tt> discussion. 
        Suppose we have a function <tt>get_employee_info</tt> that returns some employee information in a 
        <tt>tuple&lt;employee_id, salary, office&gt;</tt>. Saying something like <tt>get&lt;2&gt;(get_employee_info(...)</tt> 
        doesn&#39;t really make it that obvious that we are looking for the employee&#39;s 
        office. Furthermore, if we later become interested in returning another employee 
        attribute, we may need to adjust indexes all over the program.</p>
    <p>
        This paper proposes allowing fields to be accessed by type, so the much clearer <tt>get&lt;office&gt;(get_employee_info(...))</tt> could be used 
        interchangeably with <tt>get&lt;2&gt;(get_employee_info(...)</tt>. The only technical 
        issue is what to do if a <tt>tuple</tt> contains repeated types. In that case, we require a compile error.
        <code>tuple&lt;string, string, int&gt; t("foo", "bar", 7);
string s = get&lt;string&gt;(t);<span class="comment">  // ERROR. Ambiguous access</span></code></p>
<h3>Implementation status</h3>
    <p>
        Yes. 
        The approach in Loki suffices, because you can cast down to whichever&nbsp;<tt>Holder&lt;T&gt;</tt> you want. Also, I have my 
        Advanced C++ students implement type-addressable tuples each year.</p>
    <h2>
        Functoriality</h2>
    <p>
        The basic idea is simple. We want code like the following to work.
<code>auto funcs = make_tuple(sqrt, strlen, atof);
auto vals = make_tuple(9, &quot;foo&quot;, &quot;7.3&quot;);
auto result = funcs(vals); <span class="comment"> // result is tuple&lt;double, size_t, double&gt;(3, 3, 7.3) </span>
</code></p>
<p>Of course, there is no need to limit oneself to ordinary functions. For example,
<code>auto funcs = make_tuple(bind(std::multiplies&lt;int, int&gt;, _1, _1),
                        function(&amp;string::size),
                        [](char const *cp)-&gt;double { 
                          istringstream is(cp); double d; is >> d; return d; 
                        });
auto vals = make_tuple(9, &quot;foo&quot;, &quot;7.3&quot;);
auto result = funcs(vals); <span class="comment"> // result is tuple&lt;int, size_t, double&gt;(81, 3, 7.3) </span></code></p>
<p>For a less artificial example, consider a function <tt>get_order</tt> that returns a <tt>tuple&lt;date, 
    map&lt;item, int&gt;&gt;</tt> representing 
    an order placed by a company. Suppose we want to convert this to a point on a 
    graph, where the <em>x</em> coordinate is the day number of the date and the y 
    coordinate is the total number of items in the order:
<code>int days_from_epoch(date d);
int items_in_order(map&lt;item, int&gt; const &amp;order_items)
{
  <span class="comment">// Just add up all the order counts</span>
  return accumulate(order_items.begin(), order_items.end(), 0, 
    [](int acc, pair&lt;item, int&gt; const &amp;p) { return acc + p.second; });
}

auto point = make_tuple(days_from_epoch, items_in_order)(get_order(<span class="comment">/* ... */</span>));</code></p>
<p>Of course, the above example could have been done with a <tt>pair</tt> as easily as with a <tt>tuple</tt>, so 
    we also propose an analogous change for <tt>pair</tt>.</p>
    <h3>Variations</h3>
    <p>As an alternative to the definition of <tt>tuple::operator()</tt>, we could create a free 
        function <tt>apply</tt> in its place:
<code>auto result = apply(funcs, vals);<span class="comment">  // funcs, vals as above</span></code></p>
<dl><dt>Warning:</dt><dd>This is a different meaning than proposed for 
        <tt>apply</tt> in 
        N1483 [<a href="#ref_3">3</a>]. This is also an important use case that we 
    detailed in the EWG paper n3416. Briefly, that paper supports code like:
<code>bool f(int, double, string);
auto t = make_tuple(4, 3.14);
bool result = f(t..., "foo");</code>This provides a superset of the functionality of 
    the functionality of <tt>apply</tt> in N1483</dd></dl>
    <h3>
        Philosophy</h3>
    While the above examples are meant to stand on their own merit, 
    we can view this as desirable from a more theoretical approcah.

More formally, we can think of the type <tt>tuple</tt> as a cartesian product of its component types. One of the fundamental insights of category theory 
    (e.g., [<a href="#ref_4">4</a>]) is that cartesian products derive 
    their power because they act not only on sets, but are in fact functors (in the 
    category-theoretic sense), allowing ones to take <em>cartesian products of 
    arrows (i.e., functions)</em> [<a href="#ref_2">2</a>, &sect;6.2.17]. 
    In those terms, this proposal elevates <tt>tuple</tt> from simply being a way to 
    create new types to being a full (category-theoretic) functor.<h3>
        Implementation Status</h3>
    <p>
        Yes. Please contact the author for a copy of the implementation</p>
&nbsp;<h2>
        Wording</h2>
    <p>
        Change &sect;20.4.1 [tuple.general] paragraph 2</p>
<blockquote>
    <em>// 20.4.2.6, element access:
</em>
<pre style="margin:0;padding:0">template &lt;size_t I, class... Types&gt;
  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;) noexcept;
template &lt;size_t I, class... types>
  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp;) noexcept;
template &lt;size_t I, class... types>
  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;) noexcept;
<span class="ins">template &lt;typename T, class... Types&gt;</span>
<span class="ins">  typename T&amp; get(tuple&lt;Types...&gt;&amp;) noexcept;</span>
<span class="ins">template &lt;typename T, class... types></span>
<span class="ins">  typename T&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp;) noexcept;</span>
<span class="ins">template &lt;typename T, class... types></span>
<span class="ins">  typename T const&amp; get(const tuple&lt;Types...&gt;&amp;) noexcept;</span></pre>
</blockquote>
<p>Change &sect;20.4.2:</p>
<blockquote><tt>&nbsp;&nbsp;&nbsp;&nbsp;<em>// </em> </tt><em>20.4.2.3, </em> <tt>tuple</tt> <em>swap
</em><br/>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;void swap(tuple&amp;) noexcept(</tt>see below<tt>);</tt><br />
<tt>&nbsp;&nbsp;&nbsp;&nbsp;<span class="ins"><em>// </em> </span></tt><span class="ins"><em>20.4.2.x, </em> <tt>tuple</tt> <em>functoriality</em></span><br/>
<pre style="padding:0;margin:0">    <span class="ins">template&lt;class.. UTypes&gt;</span>
     <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(tuple&lt;UTypes...&gt; &amp;u);</span>
   <span class="ins">template&lt;class.. UTypes&gt;</span>
     <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(const tuple&lt;UTypes...&gt; &amp;u);</span>
   <span class="ins">template&lt;class.. UTypes&gt;</span>
     <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(tuple&lt;UTypes...&gt; &amp;u) const;</span>
   <span class="ins">template&lt;class.. UTypes&gt;</span>
     <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(const tuple&lt;UTypes...&gt; &amp;u) const;</span>
  };
}</pre></blockquote>
<p>Add a new section §20.4.2.x [tuple.functorial]:</p>
<blockquote><pre style="padding:0;margin:0"><span class="ins">template&lt;class.. UTypes&gt;</span>
    <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(tuple&lt;UTypes...&gt; &amp;u);</span></pre>
<pre style="padding:0;margin:0"><span class="ins">template&lt;class.. UTypes&gt;</span>
    <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(const tuple&lt;UTypes...&gt; &amp;u);</span></pre>
<pre style="padding:0;margin:0"><span class="ins">template&lt;class.. UTypes&gt;</span>
    <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(tuple&lt;UTypes...&gt; &amp;u) const;</span></pre>
<pre style="padding:0;margin:0"><span class="ins">template&lt;class.. UTypes&gt;</span>
    <span class="ins">tuple&lt;typename result_of&lt;Types(UTypes)&gt;::type...&gt;operator()(const tuple&lt;UTypes...&gt; &amp;u) const;</span></pre>
    <span class="ins"><em>Requires: </em><tt>sizeof...(Types) == sizeof...(UTypes)</tt> and for all <tt>0 &lt;= i &lt; sizeof...(Types)</tt>, the
     expression <tt>get&lt;i&gt;(*this)(get&lt;i&gt;(u))</tt> is valid.</span>
    <br />
    <span class="ins"><em>Returns:</em> The result that would be achieved by <tt>make_tuple(get&lt;0&gt;(*this)(get&lt;0&gt;(u)), get&lt;1&gt;(*this)(get&lt;0&gt;(1)),<span class="comment">/* ... */</span>).</tt></span>
</blockquote>
    <p>Add the following to the end of &sect;20.4.2.6 [tuple.elem]:</p>
<blockquote><pre style="padding:0;margin:0"><span class="ins">template &lt;typename T, class... Types&gt;</span>
<span class="ins">  T&amp; get(tuple&lt;Types...&gt;&amp; t) noexcept;</span></pre>
    <blockquote style="padding:0;margin-top:0"><span class="ins"><em>Requires:</em> The type <tt>T</tt> occurs 
        exactly once in <tt>Types...</tt>. Otherwise, the program is ill-formed.</span><br />
        <span class="ins"><em>Returns:</em> A reference to the element of <tt>t</tt> corresponding to the type <tt>T</tt> in <tt>Types...</tt></span></blockquote>
    <pre style="padding:0;margin:0"><span class="ins">template &lt;typename T, class... Types&gt;</span>
  <span class="ins">T&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t) noexcept;</span></pre>
    <blockquote style="padding:0;margin-top:0"><span class="ins"><em>Effects:</em> Equivalent to return <tt>std::forward&lt;T&amp;&amp;&gt;(get&lt;i&gt;(t));</tt></span><br />
        <span class="ins"><em>Note:</em> if a <tt>T</tt> in Types is some reference type <tt>X&amp;</tt>, the 
    return type is <tt>X&amp;</tt>, not <tt>X&amp;&amp;</tt>. However, if the element type is a non-reference type 
    <tt>T</tt>, the return type is <tt>T&amp;&amp;</tt>.</span></blockquote>
    <pre style="padding:0;margin:0"><span class="ins">template &lt;typename T, class... Types&gt;</span>
  <span class="ins">T&amp; get(const tuple&lt;Types...&gt;&amp; t) noexcept;</span></pre>
    <blockquote style="padding:0;margin-top:0"><span class="ins"><em>Requires:</em> The type <tt>T</tt> occurs 
        exactly once in <tt>Types...</tt>. Otherwise, the program is ill-formed.</span><br />
        <span class="ins"><em>Returns:</em> A const reference to the element of <tt>t</tt> corresponding to the type <tt>T</tt> in <tt>Types...</tt></span><br />
        <br />
        <span class="ins">[ <em>Note:</em> Constness is shallow. If a <tt>T</tt> in Types is some 
    reference type <tt>X&amp;</tt>, the return type is <tt>X&amp;</tt>, not <tt>const X&amp;</tt>. However, if the element 
    type is non-reference type <tt>T</tt>, the return type is <tt>const T&amp;</tt>. This is consistent 
    with how constness is defined to work for member variables of reference type.<em> 
    —end note</em> ]</span></blockquote></blockquote>
&nbsp;<h2>
        References</h2>
    <p>
        <a name="ref_1"></a>[1] Alexandrescu, <em>Modern C++ Design: Generic Programming and Design Patterns 
        Applied</em>. Addison Wesley, 2001.</p>
    <p>
        <a name="ref_2"></a>[2] Bar, <em>Category Theory. Lecture Notes for ESSLLI</em>, 
        <a href="http://www.ling.ohio-state.edu/~plummer/courses/winter09/ling681/barrwells.pdf">
        http://www.ling.ohio-state.edu/~plummer/courses/winter09/ling681/barrwells.pdf</a>.</p>
    <p>
        <a name="ref_3"></a>[3] Gregor, Powell, Järvi, Typesafe variable-length function 
        and template argument lists. Technical Report N1483=03-0066, ISO/IEC JTC 1, 
        Information technology, Subcommittee SC 22, Programming language C++, 2003.
        <a href="https://parasol.tamu.edu/~jarvi/www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1483.pdf">
        www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1483.pdf</a>.</p>
    <p>
        <a name="ref_4"></a>[4] MacLane, <em>Categories for the Working Mathematician</em>, 2<sup>nd</sup> edition.Springer-Verlag, 
        1997.</p>

        </body>
</html>
