--089e01295656f6685604faa399b3
Content-Type: text/plain; charset=UTF-8

N3602 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3602.html>
proposes
a mechanism for deducing class template parameters from an object's
initializer in certain contexts,. The proposed syntax is to use the bare
template name, without <>:

tuple t{foo, bar};

This has a significant limitation: if you want to deduce any of the
template arguments, you have to deduce all of them (except, presumably,
ones that have defaults, although the paper is not clear on this point).
This is problematic because existing class templates, unlike function
templates, are not designed to facilitate template argument deduction. They
may have so many constructor overloads that deduction is ambiguous, and
will often have constructors that don't take enough arguments to deduce all
template parameters. For example, to construct an empty std::map using this
facility, I think you'd have to supply a dummy initializer_list argument,
solely to provide a deduction hint for the first two template parameters:

std::map my_map(
    std::initializer_list<MyKey, MyValue>{},
    [](auto k1, auto k2){ return k1.foo() < k2.foo(); });

It seems to me that this problem could be solved with a simple
generalization of the proposal: permit 'auto' as a template argument in
contexts where constructor template argument deduction is possible:

std::map<MyKey, MyValue, auto> my_map(
    [](MyKey k1, MyKey k2){ return k1.foo() < k2.foo(); });

The changes to the deduction process seem like they would be relatively
trivial: the notional function templates created as part of the deduction
process would have template parameters corresponding to only the class
template arguments that have not been explicitly specified (as well as any
constructor template arguments).


A further extension is possible: with a variadic function template, you can
explicitly specify the first N template arguments, and any additional
parameters will be deduced, but even under the above proposal, you can't do
that with a variadic class template. We could make the constructor
deduction rules match the function deduction rules, so that any template
parameters not explicitly specified are eligible for deduction, but that
seems potentially confusing:

tuple<int, auto, string> tup(0, 0, "", "Surprise, this tuple has 4
elements!");

It seems like the best option would be to have an explicit syntax for
"deduce 0 or more trailing arguments":

tuple<int, auto, string, auto...> tup(0, 0, "", "No longer so surprising.");

At this point, the N3602's original syntax would just be syntactic sugar,
treating a missing template argument list as equivalent to "<auto...>". The
sugared version seems liable to confuse both tools and human readers, for
very little benefit, so I'm inclined to suggest eliminating it.


Side note: I'm ambivalent about whether to generalize these extensions so
that they apply to function templates as well. Doing so looks mechanically
straightforward, but the practical benefit is unclear, apart from general
principles of consistency and orthogonality.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01295656f6685604faa399b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2013/n3602.html">N3602</a>=C2=A0proposes a mechanism for deducing =
class template parameters from an object&#39;s initializer in certain conte=
xts,. The proposed syntax is to use the bare template name, without &lt;&gt=
;:</div>
<div><br></div><div>tuple t{foo, bar};</div><div><br></div><div>This has a =
significant limitation: if you want to deduce any of the template arguments=
, you have to deduce all of them (except, presumably, ones that have defaul=
ts, although the paper is not clear on this point). This is problematic bec=
ause existing class templates, unlike function templates, are not designed =
to facilitate template argument deduction. They may have so many constructo=
r overloads that deduction is ambiguous, and will often have constructors t=
hat don&#39;t take enough arguments to deduce all template parameters. For =
example, to construct an empty std::map using this facility, I think you&#3=
9;d have to supply a dummy initializer_list argument, solely to provide a d=
eduction hint for the first two template parameters:</div>
<div><br></div><div>std::map my_map(</div><div>=C2=A0 =C2=A0 std::initializ=
er_list&lt;MyKey, MyValue&gt;{},</div><div>=C2=A0 =C2=A0 [](auto k1, auto k=
2){ return k1.foo() &lt; k2.foo(); });</div><div><br></div><div>It seems to=
 me that this problem could be solved with a simple generalization of the p=
roposal: permit &#39;auto&#39; as a template argument in contexts where con=
structor template argument deduction is possible:</div>
<div><br></div><div>std::map&lt;MyKey, MyValue, auto&gt; my_map(</div><div>=
=C2=A0 =C2=A0=C2=A0[](MyKey k1, MyKey k2){ return k1.foo() &lt; k2.foo(); }=
);</div><div><br></div><div>The changes to the deduction process seem like =
they would be relatively trivial: the notional function templates created a=
s part of the deduction process would have template parameters correspondin=
g to only the class template arguments that have not been explicitly specif=
ied (as well as any constructor template arguments).</div>
<div><br></div><div><br></div><div>A further extension is possible: with a =
variadic function template, you can explicitly specify the first N template=
 arguments, and any additional parameters will be deduced, but even under t=
he above proposal, you can&#39;t do that with a variadic class template. We=
 could make the constructor deduction rules match the function deduction ru=
les, so that any template parameters not explicitly specified are eligible =
for deduction, but that seems potentially confusing:</div>
<div><br></div><div>tuple&lt;int, auto, string&gt; tup(0, 0, &quot;&quot;, =
&quot;Surprise, this tuple has 4 elements!&quot;);</div><div><br></div><div=
>It seems like the best option would be to have an explicit syntax for &quo=
t;deduce 0 or more trailing arguments&quot;:</div>
<div><br></div><div>tuple&lt;int, auto, string, auto...&gt; tup(0, 0, &quot=
;&quot;, &quot;No longer so surprising.&quot;);</div><div><br></div><div>At=
 this point, the N3602&#39;s original syntax would just be syntactic sugar,=
 treating a missing template argument list as equivalent to &quot;&lt;auto.=
...&gt;&quot;. The sugared version seems liable to confuse both tools and hu=
man readers, for very little benefit, so I&#39;m inclined to suggest elimin=
ating it.</div>
<div><br></div><div><br></div><div>Side note: I&#39;m ambivalent about whet=
her to generalize these extensions so that they apply to function templates=
 as well. Doing so looks mechanically straightforward, but the practical be=
nefit is unclear, apart from general principles of consistency and orthogon=
ality.</div>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01295656f6685604faa399b3--

.