------=_Part_2534_30025635.1387927977605
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Currently, it is impossible, as far as I know, to write a "
is_specialization_of" helper struct to detect whether a type is a
specialization of a given template.
It can be illustrated with the following example:
----------------------------------------------------------------------
#include <iostream>
#include <type_traits>
#include <tuple>
#include <vector>
#include <array>

template <template <class...> class Template, class T>
struct is_specialization_of
: std::false_type {};

template <template <class...> class Template, class... Args>
struct is_specialization_of<Template, Template<Args...>>
: std::true_type {};

int main()
{
    std::cout<<is_specialization_of<std::tuple,
std::tuple<double>>::value<<::std::endl;
    std::cout<<is_specialization_of<std::vector,
std::tuple<double>>::value<<::std::endl;
    std::cout<<is_specialization_of<std::array,
std::tuple<double>>::value<<::std::endl; // Error
    return 0;
}
----------------------------------------------------------------------
It works well for templates of the form template <class...> but it fails
for mixed type/variable template like std::array.
I think that it would be great (particularly for template metaprogramming)
to have a a new keyword (whose name has to be defined) to declare "a type
or a variable".
With this new keyword, one could type:
----------------------------------------------------------------------
#include <iostream>
#include <type_traits>
#include <tuple>
#include <vector>
#include <array>

template <template <keyword...> class Template, class T>
struct is_specialization_of
: std::false_type {};

template <template <keyword...> class Template, keyword... Args>
struct is_specialization_of<Template, Template<keyword...>>
: std::true_type {};

int main()
{
    std::cout<<is_specialization_of<std::tuple,
std::tuple<double>>::value<<::std::endl;
    std::cout<<is_specialization_of<std::vector,
std::tuple<double>>::value<<::std::endl;
    std::cout<<is_specialization_of<std::array,
std::tuple<double>>::value<<::std::endl; // Ok
    return 0;
}
----------------------------------------------------------------------

Has it been already discussed?
If not, what is you opinion about such a thing?
If yes, what were the issues?
Do you have any suggestion for the name of this keyword?

Thank you!

Vincent R.

--

---
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/.

------=_Part_2534_30025635.1387927977605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, <br><br>Currently, it is impossible, as far as I know,=
 to write a "<span style=3D"font-family: courier new,monospace;">is_special=
ization_of</span>" helper struct to detect whether a type is a specializati=
on of a given template.<br>It can be illustrated with the following example=
:<br><span style=3D"font-family: courier new,monospace;">------------------=
----------------------------------------------------</span><br><span style=
=3D"font-family: courier new,monospace;">#include &lt;iostream&gt;<br>#incl=
ude &lt;type_traits&gt;<br>#include &lt;tuple&gt;<br>#include &lt;vector&gt=
;<br>#include &lt;array&gt;<br><br>template &lt;template &lt;class...&gt; c=
lass Template, class T&gt;<br>struct is_specialization_of <br>: std::false_=
type {};<br>&nbsp;<br>template &lt;template &lt;class...&gt; class Template=
, class... Args&gt;<br>struct is_specialization_of&lt;Template, Template&lt=
;Args...&gt;&gt; <br>: std::true_type {};<br><br>int main()<br>{<br>&nbsp;&=
nbsp;&nbsp; std::cout&lt;&lt;is_specialization_of&lt;std::tuple,&nbsp; std:=
:tuple&lt;double&gt;&gt;::value&lt;&lt;::std::endl;<br>&nbsp;&nbsp;&nbsp; s=
td::cout&lt;&lt;is_specialization_of&lt;std::vector, std::tuple&lt;double&g=
t;&gt;::value&lt;&lt;::std::endl;<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&lt;is=
_specialization_of&lt;std::array,&nbsp; std::tuple&lt;double&gt;&gt;::value=
&lt;&lt;::std::endl; // Error<br>&nbsp;&nbsp;&nbsp; return 0;<br>}</span><b=
r><span style=3D"font-family: courier new,monospace;">---------------------=
-------------------------------------------------</span><br>It works well f=
or templates of the form <span style=3D"font-family: courier new,monospace;=
">template &lt;class...&gt;</span> but it fails for mixed type/variable tem=
plate like <span style=3D"font-family: courier new,monospace;">std::array</=
span>.<br>I think that it would be great (particularly for template metapro=
gramming) to have a a new keyword (whose name has to be defined) to declare=
 "a type or a variable".<br>With this new keyword, one could type:<br><span=
 style=3D"font-family: courier new,monospace;">----------------------------=
------------------------------------------</span><br><span style=3D"font-fa=
mily: courier new,monospace;">#include &lt;iostream&gt;<br>#include &lt;typ=
e_traits&gt;<br>#include &lt;tuple&gt;<br>#include &lt;vector&gt;<br>#inclu=
de &lt;array&gt;<br><br>template &lt;template &lt;keyword...&gt; class Temp=
late, class T&gt;<br>struct is_specialization_of <br>: std::false_type {};<=
br>&nbsp;<br>template &lt;template &lt;keyword...&gt; class Template, keywo=
rd... Args&gt;<br>struct is_specialization_of&lt;Template, Template&lt;keyw=
ord...&gt;&gt; <br>: std::true_type {};<br><br>int main()<br>{<br>&nbsp;&nb=
sp;&nbsp; std::cout&lt;&lt;is_specialization_of&lt;std::tuple,&nbsp; std::t=
uple&lt;double&gt;&gt;::value&lt;&lt;::std::endl;<br>&nbsp;&nbsp;&nbsp; std=
::cout&lt;&lt;is_specialization_of&lt;std::vector, std::tuple&lt;double&gt;=
&gt;::value&lt;&lt;::std::endl;<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&lt;is_s=
pecialization_of&lt;std::array,&nbsp; std::tuple&lt;double&gt;&gt;::value&l=
t;&lt;::std::endl; // Ok<br>&nbsp;&nbsp;&nbsp; return 0;<br>}</span><br><sp=
an style=3D"font-family: courier new,monospace;">--------------------------=
--------------------------------------------</span><br><br>Has it been alre=
ady discussed? <br>If not, what is you opinion about such a thing?<br>If ye=
s, what were the issues?<br>Do you have any suggestion for the name of this=
 keyword?<br><br>Thank you!<br><br>Vincent R.<br><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_2534_30025635.1387927977605--

.

------=_Part_2460_29359040.1387928141216
Content-Type: text/plain; charset=ISO-8859-1

Sorry, there was an error in the second example:
It is:
----------------------------------------------------------------------
template <template <keyword...> class Template, keyword... Args>
struct is_specialization_of<Template, Template<Args...>>
: std::true_type {};
----------------------------------------------------------------------
instead of:
----------------------------------------------------------------------
template <template <keyword...> class Template, keyword... Args>
struct is_specialization_of<Template, Template<keyword...>>
: std::true_type {};
----------------------------------------------------------------------

--

---
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/.

------=_Part_2460_29359040.1387928141216
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, there was an error in the second example:<br>It is:=
<br><span style=3D"font-family:courier new,monospace">---------------------=
---------<wbr>------------------------------<wbr>----------</span><br><span=
 style=3D"font-family:courier new,monospace">template &lt;template &lt;keyw=
ord...&gt; class Template, keyword... Args&gt;<br>struct is_specialization_=
of&lt;Template, Template&lt;Args...&gt;&gt; <br>: std::true_type {};</span>=
<br><span style=3D"font-family:courier new,monospace"><span style=3D"font-f=
amily:courier new,monospace">------------------------------<wbr>-----------=
-------------------<wbr>----------</span><br><span style=3D"font-family: ar=
ial,sans-serif;">instead of:</span></span><br><span style=3D"font-family:co=
urier new,monospace">------------------------------<wbr>-------------------=
-----------<wbr>----------</span><br><span style=3D"font-family:courier new=
,monospace">template &lt;template &lt;keyword...&gt; class Template, keywor=
d... Args&gt;<br>struct is_specialization_of&lt;Template, Template&lt;keywo=
rd...&gt;&gt; <br>: std::true_type {};<br></span><span style=3D"font-family=
:courier new,monospace">------------------------------<wbr>----------------=
--------------<wbr>----------</span><div dir=3D"ltr"><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_2460_29359040.1387928141216--

.

--047d7b343b50aabdbb04ef57fa9d
Content-Type: text/plain; charset=ISO-8859-1

On Tue Dec 24 2013 at 3:33:27 PM, Vincent Reverdy <vince.rev@gmail.com>
wrote:

> Hi,
>
> Currently, it is impossible, as far as I know, to write a "
> is_specialization_of" helper struct to detect whether a type is a
> specialization of a given template.
> It can be illustrated with the following example:
> ----------------------------------------------------------------------
> #include <iostream>
> #include <type_traits>
> #include <tuple>
> #include <vector>
> #include <array>
>
> template <template <class...> class Template, class T>
> struct is_specialization_of
> : std::false_type {};
>
> template <template <class...> class Template, class... Args>
> struct is_specialization_of<Template, Template<Args...>>
> : std::true_type {};
>
> int main()
> {
>     std::cout<<is_specialization_of<std::tuple,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::vector,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::array,
> std::tuple<double>>::value<<::std::endl; // Error
>     return 0;
> }
> ----------------------------------------------------------------------
> It works well for templates of the form template <class...> but it fails
> for mixed type/variable template like std::array.
> I think that it would be great (particularly for template metaprogramming)
> to have a a new keyword (whose name has to be defined) to declare "a type
> or a variable".
> With this new keyword, one could type:
> ----------------------------------------------------------------------
> #include <iostream>
> #include <type_traits>
> #include <tuple>
> #include <vector>
> #include <array>
>
> template <template <keyword...> class Template, class T>
> struct is_specialization_of
> : std::false_type {};
>
> template <template <keyword...> class Template, keyword... Args>
> struct is_specialization_of<Template, Template<keyword...>>
> : std::true_type {};
>
> int main()
> {
>     std::cout<<is_specialization_of<std::tuple,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::vector,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::array,
> std::tuple<double>>::value<<::std::endl; // Ok
>     return 0;
> }
> ----------------------------------------------------------------------
>
> Has it been already discussed?
> If not, what is you opinion about such a thing?
> If yes, what were the issues?
> Do you have any suggestion for the name of this keyword?
>

This seems like a useful addition to me, though perhaps we can get by
without introducing a new keyword. I think there was a paper on exactly
this, probably by Mike Spertus, either in 2012 or 2013, but the WG21 papers
site seems to be down at the moment so I can't easily check.

One issue springs to mind: the injected-class-name of a class template can
be used as a template template argument or as a type template argument:

template<template<typename> class> struct A {};
template<typename> struct B {};
template<typename T> struct C {
  A<C> a; // ok, pass template C
  B<C> b; // ok, pass type C<T>
};

I suppose we could (and probably should) preserve this behavior when 'C' is
passed through such a template argument, but it's a weird corner case that
you'll need to handle somehow.

Rather than introducing a new keyword, you could use a '?' token:

  template<template<? ...> class A, ? ... Ts> void f(A<Ts...>);

(or a '*' token, or something similar).

The 'auto' keyword would make sense here, but it might make more sense
being restricted to a non-type template parameter (with its type deduced
from the template argument). Perhaps it could be made to fill both roles:

  template<auto X> void f() {
    int a = X; // it's a value by default
  }
  template<auto X> void g() {
    typename X y; // it can be explicitly treated as a type
  }
  template<auto X> void h() {
    template X<int> z; // or as a template
  }
  template<auto &X> void i(); // not exactly 'auto', always a non-type
template parameter

.... though this would require a lot of hacking with the grammar, to allow
'template' and 'typename' in these new places.

--

---
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/.

--047d7b343b50aabdbb04ef57fa9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Tue Dec 24 2013 at 3:33:27 PM, Vincent Reverdy &lt;<a href=3D"mailt=
o:vince.rev@gmail.com">vince.rev@gmail.com</a>&gt; wrote:</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div dir=3D"ltr">Hi, <br><br>Currently, it is impossible, as far as I know,=
 to write a &quot;<span style=3D"font-family:courier new,monospace">is_spec=
ialization_of</span>&quot; helper struct to detect whether a type is a spec=
ialization of a given template.<br>
It can be illustrated with the following example:<br><span style=3D"font-fa=
mily:courier new,monospace">-----------------------------------------------=
-----------------------</span><br><span style=3D"font-family:courier new,mo=
nospace">#include &lt;iostream&gt;<br>
#include &lt;type_traits&gt;<br>#include &lt;tuple&gt;<br>#include &lt;vect=
or&gt;<br>#include &lt;array&gt;<br><br>template &lt;template &lt;class...&=
gt; class Template, class T&gt;<br>struct is_specialization_of <br>: std::f=
alse_type {};<br>
=A0<br>template &lt;template &lt;class...&gt; class Template, class... Args=
&gt;<br>struct is_specialization_of&lt;Template, Template&lt;Args...&gt;&gt=
; <br>: std::true_type {};<br><br>int main()<br>{<br>=A0=A0=A0 std::cout&lt=
;&lt;is_specialization_of&lt;std::tuple,=A0 std::tuple&lt;double&gt;&gt;::v=
alue&lt;&lt;::std::endl;<br>
=A0=A0=A0 std::cout&lt;&lt;is_specialization_of&lt;std::vector, std::tuple&=
lt;double&gt;&gt;::value&lt;&lt;::std::endl;<br>=A0=A0=A0 std::cout&lt;&lt;=
is_specialization_of&lt;std::array,=A0 std::tuple&lt;double&gt;&gt;::value&=
lt;&lt;::std::endl; // Error<br>
=A0=A0=A0 return 0;<br>}</span><br><span style=3D"font-family:courier new,m=
onospace">-----------------------------------------------------------------=
-----</span><br>It works well for templates of the form <span style=3D"font=
-family:courier new,monospace">template &lt;class...&gt;</span> but it fail=
s for mixed type/variable template like <span style=3D"font-family:courier =
new,monospace">std::array</span>.<br>
I think that it would be great (particularly for template metaprogramming) =
to have a a new keyword (whose name has to be defined) to declare &quot;a t=
ype or a variable&quot;.<br>With this new keyword, one could type:<br><span=
 style=3D"font-family:courier new,monospace">------------------------------=
----------------------------------------</span><br>
<span style=3D"font-family:courier new,monospace">#include &lt;iostream&gt;=
<br>#include &lt;type_traits&gt;<br>#include &lt;tuple&gt;<br>#include &lt;=
vector&gt;<br>#include &lt;array&gt;<br><br>template &lt;template &lt;keywo=
rd...&gt; class Template, class T&gt;<br>
struct is_specialization_of <br>: std::false_type {};<br>=A0<br>template &l=
t;template &lt;keyword...&gt; class Template, keyword... Args&gt;<br>struct=
 is_specialization_of&lt;Template, Template&lt;keyword...&gt;&gt; <br>: std=
::true_type {};<br>
<br>int main()<br>{<br>=A0=A0=A0 std::cout&lt;&lt;is_specialization_of&lt;s=
td::tuple,=A0 std::tuple&lt;double&gt;&gt;::value&lt;&lt;::std::endl;<br>=
=A0=A0=A0 std::cout&lt;&lt;is_specialization_of&lt;std::vector, std::tuple&=
lt;double&gt;&gt;::value&lt;&lt;::std::endl;<br>
=A0=A0=A0 std::cout&lt;&lt;is_specialization_of&lt;std::array,=A0 std::tupl=
e&lt;double&gt;&gt;::value&lt;&lt;::std::endl; // Ok<br>=A0=A0=A0 return 0;=
<br>}</span><br><span style=3D"font-family:courier new,monospace">---------=
-------------------------------------------------------------</span><br>
<br>Has it been already discussed? <br>If not, what is you opinion about su=
ch a thing?<br>If yes, what were the issues?<br>Do you have any suggestion =
for the name of this keyword?</div></blockquote><div><br></div><div>This se=
ems like a useful addition to me, though perhaps we can get by without intr=
oducing a new keyword. I think there was a paper on exactly this, probably =
by Mike Spertus, either in 2012 or 2013, but the WG21 papers site seems to =
be down at the moment so I can&#39;t easily check.</div>
<div><br></div><div>One issue springs to mind: the injected-class-name of a=
 class template can be used as a template template argument or as a type te=
mplate argument:</div><div><br></div><div>template&lt;template&lt;typename&=
gt; class&gt; struct A {};</div>
<div>template&lt;typename&gt; struct B {};</div><div>template&lt;typename T=
&gt; struct C {</div><div>=A0 A&lt;C&gt; a; // ok, pass template C</div><di=
v>=A0 B&lt;C&gt; b; // ok, pass type C&lt;T&gt;</div><div>};</div><div><br>
</div><div>I suppose we could (and probably should) preserve this behavior =
when &#39;C&#39; is passed through such a template argument, but it&#39;s a=
 weird corner case that you&#39;ll need to handle somehow.</div><div><br>
</div><div>Rather than introducing a new keyword, you could use a &#39;?&#3=
9; token:</div><div><br></div><div>=A0 template&lt;template&lt;? ...&gt; cl=
ass A, ? ... Ts&gt; void f(A&lt;Ts...&gt;);</div><div><br></div><div>(or a =
&#39;*&#39; token, or something similar).</div>
<div><br></div><div>The &#39;auto&#39; keyword would make sense here, but i=
t might make more sense being restricted to a non-type template parameter (=
with its type deduced from the template argument). Perhaps it could be made=
 to fill both roles:</div>
<div><br></div><div>=A0 template&lt;auto X&gt; void f() {</div><div>=A0 =A0=
 int a =3D X; // it&#39;s a value by default<br></div><div>=A0 }</div><div>=
=A0 template&lt;auto X&gt; void g() {</div><div>=A0 =A0 typename X y; // it=
 can be explicitly treated as a type</div>
<div>=A0 }</div><div>=A0 template&lt;auto X&gt; void h() {</div><div>=A0 =
=A0 template X&lt;int&gt; z; // or as a template</div><div>=A0 }</div><div>=
=A0 template&lt;auto &amp;X&gt; void i(); // not exactly &#39;auto&#39;, al=
ways a non-type template parameter</div>
<div><br></div><div>... though this would require a lot of hacking with the=
 grammar, to allow &#39;template&#39; and &#39;typename&#39; in these new p=
laces.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b343b50aabdbb04ef57fa9d--

.

On 1/7/14 10:17 AM, Richard Smith wrote:
> Rather than introducing a new keyword, you could use a '?' token:
>
>    template<template<? ...> class A, ? ... Ts> void f(A<Ts...>);
>
> (or a '*' token, or something similar).

This idea is unscalable if the ? represents a particular template
parameter list. If there were two template template parameters with
different lists, you would end up attempting to assign both to ? .

I'm pretty sure I wrote something about the issue on this board a while
ago, but can't recall the details.

A bare ellipsis seems to make it clearer that there is no underlying
storage or meta-variable.

template<template<...> class A, ... Ts> void f(A<Ts...>);


In this case, the template parameter list of A and the argument
types/kinds of Ts are deduced separately, and conversion potentially
occurs when forming A<Ts...> . No expressiveness is lost versus the "?"
syntax because names at the call site are determined to refer to types
or objects independently of the template parameter list, so ? would not
pass any information back to the user anyway.

> The 'auto' keyword would make sense here, but it might make more sense
> being restricted to a non-type template parameter (with its type deduced
> from the template argument). Perhaps it could be made to fill both roles:

As for the non-type role, that sounds nice as a separate proposal. The
standard explicitly mentions that it's impossible to pass a non-type
argument and deduce its type, and it makes usage of e.g.
std::integral_constant repetitive.

>
>    template<auto X> void f() {
>      int a = X; // it's a value by default
>    }
>    template<auto X> void g() {
>      typename X y; // it can be explicitly treated as a type
>    }
>    template<auto X> void h() {
>      template X<int> z; // or as a template
>    }
>    template<auto &X> void i(); // not exactly 'auto', always a non-type
> template parameter
>
> ... though this would require a lot of hacking with the grammar, to allow
> 'template' and 'typename' in these new places.

Looks like a solution in search of a problem. Every use of the parameter
would have to be disambiguated, and since the parameter can only refer
to the typename or object passed by the caller, each disambiguation
would have to go the same way. Might as well keep the status quo.

--

---
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/.

.

------=_Part_1125_5269115.1389077740219
Content-Type: text/plain; charset=ISO-8859-1

I think compile time reflection can handle this case.
Based on this paper (
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/Proposal.md
),
the result will be similar to this:


// driver
struct SpecializationDriver
{
    constexpr SpecializationDriver(const meta::template_template_decl&templateTemplateDecl
,
                                   const meta::template_decl& templateDecl)
      : result(templateTemplateDecl.getName() == templateDecl.getName()) { }
    constexpr bool result;
};

template<template <class...> class Template, class T> $use(
SpecializationDriver driver)
bool is_specialization_of()
{
   return driver.result;
}

int main()
{
    std::cout<< is_specialization_of<std::tuple,  std::tuple<double>>() <<::
std::endl;
    std::cout<< is_specialization_of<std::vector, std::tuple<double>>() <<::
std::endl;
    std::cout<< is_specialization_of<std::array,  std::tuple<double>>() <<::
std::endl;
    return 0;
}


Peter


On Wednesday, December 25, 2013 12:32:57 AM UTC+1, Vincent Reverdy wrote:
>
> Hi,
>
> Currently, it is impossible, as far as I know, to write a "
> is_specialization_of" helper struct to detect whether a type is a
> specialization of a given template.
> It can be illustrated with the following example:
> ----------------------------------------------------------------------
> #include <iostream>
> #include <type_traits>
> #include <tuple>
> #include <vector>
> #include <array>
>
> template <template <class...> class Template, class T>
> struct is_specialization_of
> : std::false_type {};
>
> template <template <class...> class Template, class... Args>
> struct is_specialization_of<Template, Template<Args...>>
> : std::true_type {};
>
> int main()
> {
>     std::cout<<is_specialization_of<std::tuple,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::vector,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::array,
> std::tuple<double>>::value<<::std::endl; // Error
>     return 0;
> }
> ----------------------------------------------------------------------
> It works well for templates of the form template <class...> but it fails
> for mixed type/variable template like std::array.
> I think that it would be great (particularly for template metaprogramming)
> to have a a new keyword (whose name has to be defined) to declare "a type
> or a variable".
> With this new keyword, one could type:
> ----------------------------------------------------------------------
> #include <iostream>
> #include <type_traits>
> #include <tuple>
> #include <vector>
> #include <array>
>
> template <template <keyword...> class Template, class T>
> struct is_specialization_of
> : std::false_type {};
>
> template <template <keyword...> class Template, keyword... Args>
> struct is_specialization_of<Template, Template<keyword...>>
> : std::true_type {};
>
> int main()
> {
>     std::cout<<is_specialization_of<std::tuple,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::vector,
> std::tuple<double>>::value<<::std::endl;
>     std::cout<<is_specialization_of<std::array,
> std::tuple<double>>::value<<::std::endl; // Ok
>     return 0;
> }
> ----------------------------------------------------------------------
>
> Has it been already discussed?
> If not, what is you opinion about such a thing?
> If yes, what were the issues?
> Do you have any suggestion for the name of this keyword?
>
> Thank you!
>
> Vincent R.
>
>

--

---
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/.

------=_Part_1125_5269115.1389077740219
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think compile time reflection can handle this case.<br>B=
ased on this paper (<a href=3D"https://github.com/hun-nemethpeter/cpp-refle=
ctor-mini/blob/master/Proposal.md">https://github.com/hun-nemethpeter/cpp-r=
eflector-mini/blob/master/Proposal.md</a>),<br>the result will be similar t=
o this:<br><br><br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// driver</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Specializatio=
nDriver</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">SpecializationDriver=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> meta</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">template_template_decl</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> templateTemplateDecl</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> <br>&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> meta</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>template_decl</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
templateDecl</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">templateTempl=
ateDecl</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">getName</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> templateDecl</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">getName</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cons=
texpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> result</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">class</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> $use</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Spec=
ializationDriver</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> driver</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> is_specialization=
_of</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> driver</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">result</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">cout</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> is_specialization_of</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">tuple</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> &nbsp;std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">tuple</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt=
;double&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">cout</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> is_specialization_of</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;double&gt;=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;()</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cout</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> is_specialization_of</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">array</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbs=
p;std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;double&gt;</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
/div></code></div><br><br>Peter<br><br><br>On Wednesday, December 25, 2013 =
12:32:57 AM UTC+1, Vincent Reverdy wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">Hi, <br><br>Currently, it is impossible, as far=
 as I know, to write a "<span style=3D"font-family:courier new,monospace">i=
s_specialization_of</span>" helper struct to detect whether a type is a spe=
cialization of a given template.<br>It can be illustrated with the followin=
g example:<br><span style=3D"font-family:courier new,monospace">-----------=
-------------------<wbr>------------------------------<wbr>----------</span=
><br><span style=3D"font-family:courier new,monospace">#include &lt;iostrea=
m&gt;<br>#include &lt;type_traits&gt;<br>#include &lt;tuple&gt;<br>#include=
 &lt;vector&gt;<br>#include &lt;array&gt;<br><br>template &lt;template &lt;=
class...&gt; class Template, class T&gt;<br>struct is_specialization_of <br=
>: std::false_type {};<br>&nbsp;<br>template &lt;template &lt;class...&gt; =
class Template, class... Args&gt;<br>struct is_specialization_of&lt;Templat=
e, Template&lt;Args...&gt;&gt; <br>: std::true_type {};<br><br>int main()<b=
r>{<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&lt;is_specialization_<wbr>of&lt;std=
::tuple,&nbsp; std::tuple&lt;double&gt;&gt;::value&lt;&lt;::<wbr>std::endl;=
<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&lt;is_specialization_<wbr>of&lt;std::v=
ector, std::tuple&lt;double&gt;&gt;::value&lt;&lt;::<wbr>std::endl;<br>&nbs=
p;&nbsp;&nbsp; std::cout&lt;&lt;is_specialization_<wbr>of&lt;std::array,&nb=
sp; std::tuple&lt;double&gt;&gt;::value&lt;&lt;::<wbr>std::endl; // Error<b=
r>&nbsp;&nbsp;&nbsp; return 0;<br>}</span><br><span style=3D"font-family:co=
urier new,monospace">------------------------------<wbr>-------------------=
-----------<wbr>----------</span><br>It works well for templates of the for=
m <span style=3D"font-family:courier new,monospace">template &lt;class...&g=
t;</span> but it fails for mixed type/variable template like <span style=3D=
"font-family:courier new,monospace">std::array</span>.<br>I think that it w=
ould be great (particularly for template metaprogramming) to have a a new k=
eyword (whose name has to be defined) to declare "a type or a variable".<br=
>With this new keyword, one could type:<br><span style=3D"font-family:couri=
er new,monospace">------------------------------<wbr>----------------------=
--------<wbr>----------</span><br><span style=3D"font-family:courier new,mo=
nospace">#include &lt;iostream&gt;<br>#include &lt;type_traits&gt;<br>#incl=
ude &lt;tuple&gt;<br>#include &lt;vector&gt;<br>#include &lt;array&gt;<br><=
br>template &lt;template &lt;keyword...&gt; class Template, class T&gt;<br>=
struct is_specialization_of <br>: std::false_type {};<br>&nbsp;<br>template=
 &lt;template &lt;keyword...&gt; class Template, keyword... Args&gt;<br>str=
uct is_specialization_of&lt;Template, Template&lt;keyword...&gt;&gt; <br>: =
std::true_type {};<br><br>int main()<br>{<br>&nbsp;&nbsp;&nbsp; std::cout&l=
t;&lt;is_specialization_<wbr>of&lt;std::tuple,&nbsp; std::tuple&lt;double&g=
t;&gt;::value&lt;&lt;::<wbr>std::endl;<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&=
lt;is_specialization_<wbr>of&lt;std::vector, std::tuple&lt;double&gt;&gt;::=
value&lt;&lt;::<wbr>std::endl;<br>&nbsp;&nbsp;&nbsp; std::cout&lt;&lt;is_sp=
ecialization_<wbr>of&lt;std::array,&nbsp; std::tuple&lt;double&gt;&gt;::val=
ue&lt;&lt;::<wbr>std::endl; // Ok<br>&nbsp;&nbsp;&nbsp; return 0;<br>}</spa=
n><br><span style=3D"font-family:courier new,monospace">-------------------=
-----------<wbr>------------------------------<wbr>----------</span><br><br=
>Has it been already discussed? <br>If not, what is you opinion about such =
a thing?<br>If yes, what were the issues?<br>Do you have any suggestion for=
 the name of this keyword?<br><br>Thank you!<br><br>Vincent R.<br><br></div=
></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_1125_5269115.1389077740219--

.

------=_Part_10518_33012136.1389125133065
Content-Type: text/plain; charset=ISO-8859-1

How it would help? `template <class...> class Template` still cant accept `
std::array<class,int>`.

On Tuesday, January 7, 2014 7:55:40 AM UTC+1, hun.nem...@gmail.com wrote:
>
> I think compile time reflection can handle this case.
> Based on this paper (
> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/Proposal.md
> ),
> the result will be similar to this:
>
>
> // driver
> struct SpecializationDriver
> {
>     constexpr SpecializationDriver(const meta::template_template_decl&templateTemplateDecl
> ,
>                                    const meta::template_decl& templateDecl
> )
>       : result(templateTemplateDecl.getName() == templateDecl.getName()) {
> }
>     constexpr bool result;
> };
>
> template<template <class...> class Template, class T> $use(
> SpecializationDriver driver)
> bool is_specialization_of()
> {
>    return driver.result;
> }
>
> int main()
> {
>     std::cout<< is_specialization_of<std::tuple,  std::tuple<double>>()
> <<::std::endl;
>     std::cout<< is_specialization_of<std::vector, std::tuple<double>>()
> <<::std::endl;
>     std::cout<< is_specialization_of<std::array,  std::tuple<double>>()
> <<::std::endl;
>     return 0;
> }
>
>
> Peter
>
>
>

--

---
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/.

------=_Part_10518_33012136.1389125133065
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How it would help? `template &lt;class...&gt; class Templa=
te` still cant accept `<code><span style=3D"color:#000">std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">arra<wbr>y</span><spa=
n style=3D"color:#660"></span></code>&lt;class,int&gt;`.<br><br>On Tuesday,=
 January 7, 2014 7:55:40 AM UTC+1, hun.nem...@gmail.com wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think compile time refle=
ction can handle this case.<br>Based on this paper (<a href=3D"https://gith=
ub.com/hun-nemethpeter/cpp-reflector-mini/blob/master/Proposal.md" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster=
%2FProposal.md\46sa\75D\46sntz\0751\46usg\75AFQjCNFS9ji6XtoUPTCic92mCjgbLYX=
nnQ';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmas=
ter%2FProposal.md\46sa\75D\46sntz\0751\46usg\75AFQjCNFS9ji6XtoUPTCic92mCjgb=
LYXnnQ';return true;">https://github.com/hun-<wbr>nemethpeter/cpp-reflector=
-<wbr>mini/blob/master/Proposal.md</a>),<br>the result will be similar to t=
his:<br><br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#800">// driver</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#008">struct</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#606">SpecializationDriver</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#008">=
constexpr</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">SpecializationDriver</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#008">const</span><span style=3D"color:#000"> meta</span><span s=
tyle=3D"color:#660">::</span><span style=3D"color:#000">template_template_d=
ecl</span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000"=
> templateTemplateDecl</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</sp=
an><span style=3D"color:#008">const</span><span style=3D"color:#000"> meta<=
/span><span style=3D"color:#660">::</span><span style=3D"color:#000">templa=
te_decl</span><span style=3D"color:#660">&amp;</span><span style=3D"color:#=
000"> templateDecl</span><span style=3D"color:#660">)</span><span style=3D"=
color:#000"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#660">:</s=
pan><span style=3D"color:#000"> result</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">templateTemplateDecl</span><span style=3D"c=
olor:#660">.</span><span style=3D"color:#000">ge<wbr>tName</span><span styl=
e=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D=3D</span><span style=3D"color:#000"> templateDecl</span><s=
pan style=3D"color:#660">.</span><span style=3D"color:#000">getName</span><=
span style=3D"color:#660">())</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">}</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </sp=
an><span style=3D"color:#008">constexpr</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> res=
ult</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>=
<br></span><span style=3D"color:#008">template</span><span style=3D"color:#=
660">&lt;</span><span style=3D"color:#008">template</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"colo=
r:#008">class</span><span style=3D"color:#660">...&gt;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">class</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">Template</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">class</span><span style=3D"color:#000"> T</span><span style=3D"c=
olor:#660">&gt;</span><span style=3D"color:#000"> $use</span><span style=3D=
"color:#660">(</span><span style=3D"color:#606">SpecializationDriver</span>=
<span style=3D"color:#000"> driver</span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">bool</spa=
n><span style=3D"color:#000"> is_specialization_of</span><span style=3D"col=
or:#660">()</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp;</span><span st=
yle=3D"color:#008">return</span><span style=3D"color:#000"> driver</span><s=
pan style=3D"color:#660">.</span><span style=3D"color:#000">result</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#000"><br></span><span style=3D"color:#008">int</span><span =
style=3D"color:#000"> main</span><span style=3D"color:#660">()</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br>&nbsp; &nbsp; std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">cout</span><span style=3D"color:#660">&l=
t;&lt;</span><span style=3D"color:#000"> is_specialization_of</span><span s=
tyle=3D"color:#660">&lt;</span><span style=3D"color:#000">std</span><span s=
tyle=3D"color:#660">::</span><span style=3D"color:#000">tupl<wbr>e</span><s=
pan style=3D"color:#660">,</span><span style=3D"color:#000"> &nbsp;std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#000">tuple</spa=
n><span style=3D"color:#080">&lt;double&gt;</span><span style=3D"color:#660=
">&gt;()</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">&lt;&lt;::</span><span style=3D"color:#000">std</span><span style=3D"colo=
r:#660">::</span><span style=3D"color:#000">endl</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>&nbsp; &nbsp; std</span><span=
 style=3D"color:#660">::</span><span style=3D"color:#000">cout</span><span =
style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> is_speciali=
zation_of</span><span style=3D"color:#660">&lt;</span><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">vect<wbr>or</span><span style=3D"color:#660">,</span><span style=3D"col=
or:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">tuple</span><span style=3D"color:#080">&lt;double&gt;</span><span s=
tyle=3D"color:#660">&gt;()</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">&lt;&lt;::</span><span style=3D"color:#000">std</span><=
span style=3D"color:#660">::</span><span style=3D"color:#000">endl</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; &nbs=
p; std</span><span style=3D"color:#660">::</span><span style=3D"color:#000"=
>cout</span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:=
#000"> is_specialization_of</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span=
 style=3D"color:#000">arra<wbr>y</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> &nbsp;std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">tuple</span><span style=3D"color:#080">&lt;d=
ouble&gt;</span><span style=3D"color:#660">&gt;()</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">&lt;&lt;::</span><span style=3D"=
color:#000">std</span><span style=3D"color:#660">::</span><span style=3D"co=
lor:#000">endl</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#008">return</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">}</span></div></code></div><br><br>Peter<br><br><div dir=
=3D"ltr"><br></div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_10518_33012136.1389125133065--

.

------=_Part_14996_4010857.1389160577334
Content-Type: text/plain; charset=ISO-8859-1

You are right, it will not help. I didn't realized that template <class...>
class Template` cant accept `std::array<class,int>.
I thought that the problem occurs in Template<Args...>.

Peter


On Tuesday, January 7, 2014 9:05:33 PM UTC+1, inkwizyt...@gmail.com wrote:
>
> How it would help? `template <class...> class Template` still cant accept `
> std::array<class,int>`.
>
>

--

---
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/.

------=_Part_14996_4010857.1389160577334
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You are right, it will not help. I didn't realized that te=
mplate &lt;class...&gt; class Template` cant accept `<code><span style=3D"c=
olor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">array</span><span style=3D"color:#660"></span></code>&lt;class,int=
&gt;.<br>I thought that the problem occurs in <span style=3D"font-family:co=
urier new,monospace">Template&lt;Args...&gt;</span>.<br><br>Peter<br><br><b=
r>On Tuesday, January 7, 2014 9:05:33 PM UTC+1, inkwizyt...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">How it would=
 help? `template &lt;class...&gt; class Template` still cant accept `<code>=
<span style=3D"color:#000">std</span><span style=3D"color:#660">::</span><s=
pan style=3D"color:#000">array</span><span style=3D"color:#660"></span></co=
de>&lt;class,int&gt;`.<br><br></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_14996_4010857.1389160577334--

.

--089e0160cdf8b80f7f04ef7c1fd8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <potswa@gmail.com> wrote:

> On 1/7/14 10:17 AM, Richard Smith wrote:
>
>> Rather than introducing a new keyword, you could use a '?' token:
>>
>>    template<template<? ...> class A, ? ... Ts> void f(A<Ts...>);
>>
>> (or a '*' token, or something similar).
>>
>
> This idea is unscalable if the ? represents a particular template
> parameter list. If there were two template template parameters with
> different lists, you would end up attempting to assign both to ? .
>

That's not the idea. ? doesn't get assigned a value, it just means "any
type, non-type, or template template argument is OK here", exactly as the
original poster requested. So <? ...> is exactly equivalent to your
suggested <...>.


> I'm pretty sure I wrote something about the issue on this board a while
> ago, but can't recall the details.
>
> A bare ellipsis seems to make it clearer that there is no underlying
> storage or meta-variable.
>
> template<template<...> class A, ... Ts> void f(A<Ts...>);
>

This does not seem like a complete solution, because it does not provide a
way to have a *single* template parameter of any kind. That in turn can be
useful if generic code wants to process an arbitrary list of template
arguments in some way:

  template<? ...> struct do_stuff { using type = void; };
  template<? X, ? ...Xs> struct do_stuff<X, Xs...> { using type =
foo<bar<X>, typename do_stuff<Xs...>::type>; };

In this case, the template parameter list of A and the argument types/kinds
> of Ts are deduced separately, and conversion potentially occurs when
> forming A<Ts...> . No expressiveness is lost versus the "?" syntax because
> names at the call site are determined to refer to types or objects
> independently of the template parameter list, so ? would not pass any
> information back to the user anyway.
>
>
>  The 'auto' keyword would make sense here, but it might make more sense
>> being restricted to a non-type template parameter (with its type deduced
>> from the template argument). Perhaps it could be made to fill both roles:
>>
>
> As for the non-type role, that sounds nice as a separate proposal. The
> standard explicitly mentions that it's impossible to pass a non-type
> argument and deduce its type, and it makes usage of e.g.
> std::integral_constant repetitive.


Yes, there's probably an argument for having both, even though there's a
lot of overlap between them.


>
>>    template<auto X> void f() {
>>      int a = X; // it's a value by default
>>    }
>>    template<auto X> void g() {
>>      typename X y; // it can be explicitly treated as a type
>>    }
>>    template<auto X> void h() {
>>      template X<int> z; // or as a template
>>    }
>>    template<auto &X> void i(); // not exactly 'auto', always a non-type
>> template parameter
>>
>> ... though this would require a lot of hacking with the grammar, to allow
>> 'template' and 'typename' in these new places.
>>
>
> Looks like a solution in search of a problem. Every use of the parameter
> would have to be disambiguated, and since the parameter can only refer to
> the typename or object passed by the caller, each disambiguation would have
> to go the same way. Might as well keep the status quo.


Uses as a non-type parameter would not need disambiguation, and it solves
both the problem originally raised in this thread and the more-constrained
problem raised in the "T for two" section of N3405 and the resulting N3601.
But I agree that separate syntax for the two problems is probably the
better choice -- I was just pointing out that it's not the only option.

--

---
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/.

--089e0160cdf8b80f7f04ef7c1fd8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 6, 2014 at 7:31 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 1/7/14 10:17 AM, Richar=
d Smith wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Rather than introducing a new keyword, you could use a &#39;?&#39; token:<b=
r>
<br>
=A0 =A0template&lt;template&lt;? ...&gt; class A, ? ... Ts&gt; void f(A&lt;=
Ts...&gt;);<br>
<br>
(or a &#39;*&#39; token, or something similar).<br>
</blockquote>
<br></div>
This idea is unscalable if the ? represents a particular template parameter=
 list. If there were two template template parameters with different lists,=
 you would end up attempting to assign both to ? .<br></blockquote><div>
<br></div><div>That&#39;s not the idea. ? doesn&#39;t get assigned a value,=
 it just means &quot;any type, non-type, or template template argument is O=
K here&quot;, exactly as the original poster requested. So &lt;? ...&gt; is=
 exactly equivalent to your suggested &lt;...&gt;.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
I&#39;m pretty sure I wrote something about the issue on this board a while=
 ago, but can&#39;t recall the details.<br>
<br>
A bare ellipsis seems to make it clearer that there is no underlying storag=
e or meta-variable.<br>
<br>
template&lt;template&lt;...&gt; class A, ... Ts&gt; void f(A&lt;Ts...&gt;);=
<br></blockquote><div><br></div><div>This does not seem like a complete sol=
ution, because it does not provide a way to have a *single* template parame=
ter of any kind. That in turn can be useful if generic code wants to proces=
s an arbitrary list of template arguments in some way:</div>
<div><br></div><div>=A0 template&lt;? ...&gt; struct do_stuff { using type =
=3D void; };</div><div>=A0 template&lt;? X, ? ...Xs&gt; struct do_stuff&lt;=
X, Xs...&gt; { using type =3D foo&lt;bar&lt;X&gt;, typename do_stuff&lt;Xs.=
...&gt;::type&gt;; };<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the template parameter list of A and the argument types/kinds=
 of Ts are deduced separately, and conversion potentially occurs when formi=
ng A&lt;Ts...&gt; . No expressiveness is lost versus the &quot;?&quot; synt=
ax because names at the call site are determined to refer to types or objec=
ts independently of the template parameter list, so ? would not pass any in=
formation back to the user anyway.<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The &#39;auto&#39; keyword would make sense here, but it might make more se=
nse<br>
being restricted to a non-type template parameter (with its type deduced<br=
>
from the template argument). Perhaps it could be made to fill both roles:<b=
r>
</blockquote>
<br></div>
As for the non-type role, that sounds nice as a separate proposal. The stan=
dard explicitly mentions that it&#39;s impossible to pass a non-type argume=
nt and deduce its type, and it makes usage of e.g. std::integral_constant r=
epetitive.</blockquote>
<div><br></div><div>Yes, there&#39;s probably an argument for having both, =
even though there&#39;s a lot of overlap between them.</div><div>=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
=A0 =A0template&lt;auto X&gt; void f() {<br>
=A0 =A0 =A0int a =3D X; // it&#39;s a value by default<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto X&gt; void g() {<br>
=A0 =A0 =A0typename X y; // it can be explicitly treated as a type<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto X&gt; void h() {<br>
=A0 =A0 =A0template X&lt;int&gt; z; // or as a template<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto &amp;X&gt; void i(); // not exactly &#39;auto&#39;,=
 always a non-type<br>
template parameter<br>
<br>
.... though this would require a lot of hacking with the grammar, to allow<b=
r>
&#39;template&#39; and &#39;typename&#39; in these new places.<br>
</blockquote>
<br></div>
Looks like a solution in search of a problem. Every use of the parameter wo=
uld have to be disambiguated, and since the parameter can only refer to the=
 typename or object passed by the caller, each disambiguation would have to=
 go the same way. Might as well keep the status quo.</blockquote>
<div><br></div><div>Uses as a non-type parameter would not need disambiguat=
ion, and it solves both the problem originally raised in this thread and th=
e more-constrained problem raised in the &quot;T for two&quot; section of N=
3405 and the resulting N3601. But I agree that separate syntax for the two =
problems is probably the better choice -- I was just pointing out that it&#=
39;s not the only option.</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0160cdf8b80f7f04ef7c1fd8--

.

------=_Part_742_28447818.1389222526249
Content-Type: text/plain; charset=ISO-8859-1

I agree that something like your ? is needed to be able to disassemble the
list of template arguments.

We would also need some way to overload based on whether the "head", i.e.
your ?X is a type or a value. Maybe this can be done with partial class
template specialization already with the aid of SFINAE but what we need to
boil it down to is:

is_type<?X>::value to be true or false depending on if X is a type or a
value.

If it is not a type we also need to know the type of the value, which I
imagine can be done with decltype(X) iff X is not a type.

To make sure that we don't use this decltype erroneously we would have to
specialize helper templates on is_type<?X>::value in the regular template
programming style unless we get a static if so that a more imperative style
can be used.


Here is a try at implementing is_type:

// Base declaration;
template<?X> struct is_type;

// Specialization for typename:
template<> struct is_type<typename X> { static const bool value = true; }
template<typename T> is_type<T X> { static const bool value = false; }

Does this make any sense? I'm very uncertain about the empty <> in the
first specialization, is it logical at all?

Whatever solution can be found to this detail it is important that it can
be done, it is nice if it can be done without introducing any more language
features than the ? itself. It is also good if such a trait would be added
to the standard library to avoid having to invent it over and over.






Den onsdagen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith:
>
> On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <pot...@gmail.com<javascript:>
> > wrote:
>
>> On 1/7/14 10:17 AM, Richard Smith wrote:
>>
>>> Rather than introducing a new keyword, you could use a '?' token:
>>>
>>>    template<template<? ...> class A, ? ... Ts> void f(A<Ts...>);
>>>
>>> (or a '*' token, or something similar).
>>>
>>
>> This idea is unscalable if the ? represents a particular template
>> parameter list. If there were two template template parameters with
>> different lists, you would end up attempting to assign both to ? .
>>
>
> That's not the idea. ? doesn't get assigned a value, it just means "any
> type, non-type, or template template argument is OK here", exactly as the
> original poster requested. So <? ...> is exactly equivalent to your
> suggested <...>.
>
>
>> I'm pretty sure I wrote something about the issue on this board a while
>> ago, but can't recall the details.
>>
>> A bare ellipsis seems to make it clearer that there is no underlying
>> storage or meta-variable.
>>
>> template<template<...> class A, ... Ts> void f(A<Ts...>);
>>
>
> This does not seem like a complete solution, because it does not provide a
> way to have a *single* template parameter of any kind. That in turn can be
> useful if generic code wants to process an arbitrary list of template
> arguments in some way:
>
>   template<? ...> struct do_stuff { using type = void; };
>   template<? X, ? ...Xs> struct do_stuff<X, Xs...> { using type =
> foo<bar<X>, typename do_stuff<Xs...>::type>; };
>
> In this case, the template parameter list of A and the argument
>> types/kinds of Ts are deduced separately, and conversion potentially occurs
>> when forming A<Ts...> . No expressiveness is lost versus the "?" syntax
>> because names at the call site are determined to refer to types or objects
>> independently of the template parameter list, so ? would not pass any
>> information back to the user anyway.
>>
>>
>>  The 'auto' keyword would make sense here, but it might make more sense
>>> being restricted to a non-type template parameter (with its type deduced
>>> from the template argument). Perhaps it could be made to fill both roles:
>>>
>>
>> As for the non-type role, that sounds nice as a separate proposal. The
>> standard explicitly mentions that it's impossible to pass a non-type
>> argument and deduce its type, and it makes usage of e.g.
>> std::integral_constant repetitive.
>
>
> Yes, there's probably an argument for having both, even though there's a
> lot of overlap between them.
>
>
>>
>>>    template<auto X> void f() {
>>>      int a = X; // it's a value by default
>>>    }
>>>    template<auto X> void g() {
>>>      typename X y; // it can be explicitly treated as a type
>>>    }
>>>    template<auto X> void h() {
>>>      template X<int> z; // or as a template
>>>    }
>>>    template<auto &X> void i(); // not exactly 'auto', always a non-type
>>> template parameter
>>>
>>> ... though this would require a lot of hacking with the grammar, to allow
>>> 'template' and 'typename' in these new places.
>>>
>>
>> Looks like a solution in search of a problem. Every use of the parameter
>> would have to be disambiguated, and since the parameter can only refer to
>> the typename or object passed by the caller, each disambiguation would have
>> to go the same way. Might as well keep the status quo.
>
>
> Uses as a non-type parameter would not need disambiguation, and it solves
> both the problem originally raised in this thread and the more-constrained
> problem raised in the "T for two" section of N3405 and the resulting N3601.
> But I agree that separate syntax for the two problems is probably the
> better choice -- I was just pointing out that it's not the only option.
>

--

---
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/.

------=_Part_742_28447818.1389222526249
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree that something like your ? is needed to be able to=
 disassemble the list of template arguments.<div><br></div><div>We would al=
so need some way to overload based on whether the "head", i.e. your ?X is a=
 type or a value. Maybe this can be done with partial class template specia=
lization already with the aid of SFINAE but what we need to boil it down to=
 is:</div><div><br></div><div>is_type&lt;?X&gt;::value to be true or false =
depending on if X is a type or a value.</div><div><br></div><div>If it is n=
ot a type we also need to know the type of the value, which I imagine can b=
e done with decltype(X) iff X is not a type.</div><div><br></div><div>To ma=
ke sure that we don't use this decltype erroneously we would have to specia=
lize helper templates on is_type&lt;?X&gt;::value in the regular template p=
rogramming style unless we get a static if so that a more imperative style =
can be used.</div><div><br></div><div><br></div><div>Here is a try at imple=
menting is_type:</div><div><br></div><div>// Base declaration;</div><div>te=
mplate&lt;?X&gt; struct is_type;</div><div><br></div><div>// Specialization=
 for typename:</div><div>template&lt;&gt; struct is_type&lt;typename X&gt; =
{ static const bool value =3D true; }</div><div>template&lt;typename T&gt; =
is_type&lt;T X&gt; { static const bool value =3D false; }</div><div><br></d=
iv><div>Does this make any sense? I'm very uncertain about the empty &lt;&g=
t; in the first specialization, is it logical at all?</div><div><br></div><=
div>Whatever solution can be found to this detail it is important that it c=
an be done, it is nice if it can be done without introducing any more langu=
age features than the ? itself. It is also good if such a trait would be ad=
ded to the standard library to avoid having to invent it over and over.</di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br>=
Den onsdagen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"0L6E4bwdk9EJ" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">pot...@gmail.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 1/7/14 10:17 AM, Richard Smith wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Rather than introducing a new keyword, you could use a '?' token:<br>
<br>
&nbsp; &nbsp;template&lt;template&lt;? ...&gt; class A, ? ... Ts&gt; void f=
(A&lt;Ts...&gt;);<br>
<br>
(or a '*' token, or something similar).<br>
</blockquote>
<br></div>
This idea is unscalable if the ? represents a particular template parameter=
 list. If there were two template template parameters with different lists,=
 you would end up attempting to assign both to ? .<br></blockquote><div>
<br></div><div>That's not the idea. ? doesn't get assigned a value, it just=
 means "any type, non-type, or template template argument is OK here", exac=
tly as the original poster requested. So &lt;? ...&gt; is exactly equivalen=
t to your suggested &lt;...&gt;.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
I'm pretty sure I wrote something about the issue on this board a while ago=
, but can't recall the details.<br>
<br>
A bare ellipsis seems to make it clearer that there is no underlying storag=
e or meta-variable.<br>
<br>
template&lt;template&lt;...&gt; class A, ... Ts&gt; void f(A&lt;Ts...&gt;);=
<br></blockquote><div><br></div><div>This does not seem like a complete sol=
ution, because it does not provide a way to have a *single* template parame=
ter of any kind. That in turn can be useful if generic code wants to proces=
s an arbitrary list of template arguments in some way:</div>
<div><br></div><div>&nbsp; template&lt;? ...&gt; struct do_stuff { using ty=
pe =3D void; };</div><div>&nbsp; template&lt;? X, ? ...Xs&gt; struct do_stu=
ff&lt;X, Xs...&gt; { using type =3D foo&lt;bar&lt;X&gt;, typename do_stuff&=
lt;Xs...&gt;::type&gt;; };<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the template parameter list of A and the argument types/kinds=
 of Ts are deduced separately, and conversion potentially occurs when formi=
ng A&lt;Ts...&gt; . No expressiveness is lost versus the "?" syntax because=
 names at the call site are determined to refer to types or objects indepen=
dently of the template parameter list, so ? would not pass any information =
back to the user anyway.<div>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The 'auto' keyword would make sense here, but it might make more sense<br>
being restricted to a non-type template parameter (with its type deduced<br=
>
from the template argument). Perhaps it could be made to fill both roles:<b=
r>
</blockquote>
<br></div>
As for the non-type role, that sounds nice as a separate proposal. The stan=
dard explicitly mentions that it's impossible to pass a non-type argument a=
nd deduce its type, and it makes usage of e.g. std::integral_constant repet=
itive.</blockquote>
<div><br></div><div>Yes, there's probably an argument for having both, even=
 though there's a lot of overlap between them.</div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
&nbsp; &nbsp;template&lt;auto X&gt; void f() {<br>
&nbsp; &nbsp; &nbsp;int a =3D X; // it's a value by default<br>
&nbsp; &nbsp;}<br>
&nbsp; &nbsp;template&lt;auto X&gt; void g() {<br>
&nbsp; &nbsp; &nbsp;typename X y; // it can be explicitly treated as a type=
<br>
&nbsp; &nbsp;}<br>
&nbsp; &nbsp;template&lt;auto X&gt; void h() {<br>
&nbsp; &nbsp; &nbsp;template X&lt;int&gt; z; // or as a template<br>
&nbsp; &nbsp;}<br>
&nbsp; &nbsp;template&lt;auto &amp;X&gt; void i(); // not exactly 'auto', a=
lways a non-type<br>
template parameter<br>
<br>
.... though this would require a lot of hacking with the grammar, to allow<b=
r>
'template' and 'typename' in these new places.<br>
</blockquote>
<br></div>
Looks like a solution in search of a problem. Every use of the parameter wo=
uld have to be disambiguated, and since the parameter can only refer to the=
 typename or object passed by the caller, each disambiguation would have to=
 go the same way. Might as well keep the status quo.</blockquote>
<div><br></div><div>Uses as a non-type parameter would not need disambiguat=
ion, and it solves both the problem originally raised in this thread and th=
e more-constrained problem raised in the "T for two" section of N3405 and t=
he resulting N3601. But I agree that separate syntax for the two problems i=
s probably the better choice -- I was just pointing out that it's not the o=
nly option.</div>
</div></div></div>
</blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_742_28447818.1389222526249--

.

--047d7b86e48259903004ef7eea51
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 8, 2014 at 3:08 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I agree that something like your ? is needed to be able to disassemble the
> list of template arguments.
>
> We would also need some way to overload based on whether the "head", i.e.
> your ?X is a type or a value. Maybe this can be done with partial class
> template specialization already with the aid of SFINAE but what we need to
> boil it down to is:
>
> is_type<?X>::value to be true or false depending on if X is a type or a
> value.
>
> If it is not a type we also need to know the type of the value, which I
> imagine can be done with decltype(X) iff X is not a type.
>

Here's an implementation:

  template<? X> struct is_type : std::false_type {};
  template<typename T> struct is_type<T> : std::true_type {};

(and likewise we can implement is_template and is_nontype).

To make sure that we don't use this decltype erroneously we would have to
> specialize helper templates on is_type<?X>::value in the regular template
> programming style unless we get a static if so that a more imperative style
> can be used.
>
>
> Here is a try at implementing is_type:
>
> // Base declaration;
> template<?X> struct is_type;
>
> // Specialization for typename:
> template<> struct is_type<typename X> { static const bool value = true; }
> template<typename T> is_type<T X> { static const bool value = false; }
>
> Does this make any sense? I'm very uncertain about the empty <> in the
> first specialization, is it logical at all?
>

The <> doesn't make sense here; that'd be the syntax for an explicit
specialization, which is not what you want here.


> Whatever solution can be found to this detail it is important that it can
> be done, it is nice if it can be done without introducing any more language
> features than the ? itself. It is also good if such a trait would be added
> to the standard library to avoid having to invent it over and over.
>

Yes, I think the ? extension alone is sufficient for this.

With the addition of some motivating examples, this seems ready to be
written up as a paper to me. I'm somewhat optimistic that the most
contentious part of this will be the syntax ('?' or 'auto' or a new keyword
or something else).


> Den onsdagen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith:
>
>> On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <pot...@gmail.com> wrote:
>>
>>> On 1/7/14 10:17 AM, Richard Smith wrote:
>>>
>>>> Rather than introducing a new keyword, you could use a '?' token:
>>>>
>>>>    template<template<? ...> class A, ? ... Ts> void f(A<Ts...>);
>>>>
>>>> (or a '*' token, or something similar).
>>>>
>>>
>>> This idea is unscalable if the ? represents a particular template
>>> parameter list. If there were two template template parameters with
>>> different lists, you would end up attempting to assign both to ? .
>>>
>>
>> That's not the idea. ? doesn't get assigned a value, it just means "any
>> type, non-type, or template template argument is OK here", exactly as the
>> original poster requested. So <? ...> is exactly equivalent to your
>> suggested <...>.
>>
>>
>>> I'm pretty sure I wrote something about the issue on this board a while
>>> ago, but can't recall the details.
>>>
>>> A bare ellipsis seems to make it clearer that there is no underlying
>>> storage or meta-variable.
>>>
>>> template<template<...> class A, ... Ts> void f(A<Ts...>);
>>>
>>
>> This does not seem like a complete solution, because it does not provide
>> a way to have a *single* template parameter of any kind. That in turn can
>> be useful if generic code wants to process an arbitrary list of template
>> arguments in some way:
>>
>>   template<? ...> struct do_stuff { using type = void; };
>>   template<? X, ? ...Xs> struct do_stuff<X, Xs...> { using type =
>> foo<bar<X>, typename do_stuff<Xs...>::type>; };
>>
>> In this case, the template parameter list of A and the argument
>>> types/kinds of Ts are deduced separately, and conversion potentially occurs
>>> when forming A<Ts...> . No expressiveness is lost versus the "?" syntax
>>> because names at the call site are determined to refer to types or objects
>>> independently of the template parameter list, so ? would not pass any
>>> information back to the user anyway.
>>>
>>>
>>>  The 'auto' keyword would make sense here, but it might make more sense
>>>> being restricted to a non-type template parameter (with its type deduced
>>>> from the template argument). Perhaps it could be made to fill both
>>>> roles:
>>>>
>>>
>>> As for the non-type role, that sounds nice as a separate proposal. The
>>> standard explicitly mentions that it's impossible to pass a non-type
>>> argument and deduce its type, and it makes usage of e.g.
>>> std::integral_constant repetitive.
>>
>>
>> Yes, there's probably an argument for having both, even though there's a
>> lot of overlap between them.
>>
>>
>>>
>>>>    template<auto X> void f() {
>>>>      int a = X; // it's a value by default
>>>>    }
>>>>    template<auto X> void g() {
>>>>      typename X y; // it can be explicitly treated as a type
>>>>    }
>>>>    template<auto X> void h() {
>>>>      template X<int> z; // or as a template
>>>>    }
>>>>    template<auto &X> void i(); // not exactly 'auto', always a non-type
>>>> template parameter
>>>>
>>>> ... though this would require a lot of hacking with the grammar, to
>>>> allow
>>>> 'template' and 'typename' in these new places.
>>>>
>>>
>>> Looks like a solution in search of a problem. Every use of the parameter
>>> would have to be disambiguated, and since the parameter can only refer to
>>> the typename or object passed by the caller, each disambiguation would have
>>> to go the same way. Might as well keep the status quo.
>>
>>
>> Uses as a non-type parameter would not need disambiguation, and it solves
>> both the problem originally raised in this thread and the more-constrained
>> problem raised in the "T for two" section of N3405 and the resulting N3601.
>> But I agree that separate syntax for the two problems is probably the
>> better choice -- I was just pointing out that it's not the only option.
>>
>  --
>
> ---
> 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/.
>

--

---
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/.

--047d7b86e48259903004ef7eea51
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 8, 2014 at 3:08 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsso=
n@beamways.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I agree that something like=
 your ? is needed to be able to disassemble the list of template arguments.=
<div>
<br></div><div>We would also need some way to overload based on whether the=
 &quot;head&quot;, i.e. your ?X is a type or a value. Maybe this can be don=
e with partial class template specialization already with the aid of SFINAE=
 but what we need to boil it down to is:</div>
<div><br></div><div>is_type&lt;?X&gt;::value to be true or false depending =
on if X is a type or a value.</div><div><br></div><div>If it is not a type =
we also need to know the type of the value, which I imagine can be done wit=
h decltype(X) iff X is not a type.</div>
</div></blockquote><div><br></div><div>Here&#39;s an implementation:</div><=
div><br></div><div>=A0 template&lt;? X&gt; struct is_type : std::false_type=
 {};</div><div>=A0 template&lt;typename T&gt; struct is_type&lt;T&gt; : std=
::true_type {};</div>
<div><br></div><div>(and likewise we can implement is_template and is_nonty=
pe).</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>
To make sure that we don&#39;t use this decltype erroneously we would have =
to specialize helper templates on is_type&lt;?X&gt;::value in the regular t=
emplate programming style unless we get a static if so that a more imperati=
ve style can be used.</div>
<div><br></div><div><br></div><div>Here is a try at implementing is_type:</=
div><div><br></div><div>// Base declaration;</div><div>template&lt;?X&gt; s=
truct is_type;</div><div><br></div><div>// Specialization for typename:</di=
v>
<div>template&lt;&gt; struct is_type&lt;typename X&gt; { static const bool =
value =3D true; }</div><div>template&lt;typename T&gt; is_type&lt;T X&gt; {=
 static const bool value =3D false; }</div><div><br></div><div>Does this ma=
ke any sense? I&#39;m very uncertain about the empty &lt;&gt; in the first =
specialization, is it logical at all?</div>
</div></blockquote><div><br></div><div>The &lt;&gt; doesn&#39;t make sense =
here; that&#39;d be the syntax for an explicit specialization, which is not=
 what you want here.</div><div>=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>Whatever solution can be found to this detail it is i=
mportant that it can be done, it is nice if it can be done without introduc=
ing any more language features than the ? itself. It is also good if such a=
 trait would be added to the standard library to avoid having to invent it =
over and over.</div>
</div></blockquote><div><br></div><div>Yes, I think the ? extension alone i=
s sufficient for this.</div><div><br></div><div>With the addition of some m=
otivating examples, this seems ready to be written up as a paper to me. I&#=
39;m somewhat optimistic that the most contentious part of this will be the=
 syntax (&#39;?&#39; or &#39;auto&#39; or a new keyword or something else).=
</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Den onsd=
agen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith:<div><div =
class=3D"h5">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <span dir=3D"ltr=
">&lt;<a>pot...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 1/7/14 10:17 AM, Richard Smith wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Rather than introducing a new keyword, you could use a &#39;?&#39; token:<b=
r>
<br>
=A0 =A0template&lt;template&lt;? ...&gt; class A, ? ... Ts&gt; void f(A&lt;=
Ts...&gt;);<br>
<br>
(or a &#39;*&#39; token, or something similar).<br>
</blockquote>
<br></div>
This idea is unscalable if the ? represents a particular template parameter=
 list. If there were two template template parameters with different lists,=
 you would end up attempting to assign both to ? .<br></blockquote><div>

<br></div><div>That&#39;s not the idea. ? doesn&#39;t get assigned a value,=
 it just means &quot;any type, non-type, or template template argument is O=
K here&quot;, exactly as the original poster requested. So &lt;? ...&gt; is=
 exactly equivalent to your suggested &lt;...&gt;.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
I&#39;m pretty sure I wrote something about the issue on this board a while=
 ago, but can&#39;t recall the details.<br>
<br>
A bare ellipsis seems to make it clearer that there is no underlying storag=
e or meta-variable.<br>
<br>
template&lt;template&lt;...&gt; class A, ... Ts&gt; void f(A&lt;Ts...&gt;);=
<br></blockquote><div><br></div><div>This does not seem like a complete sol=
ution, because it does not provide a way to have a *single* template parame=
ter of any kind. That in turn can be useful if generic code wants to proces=
s an arbitrary list of template arguments in some way:</div>

<div><br></div><div>=A0 template&lt;? ...&gt; struct do_stuff { using type =
=3D void; };</div><div>=A0 template&lt;? X, ? ...Xs&gt; struct do_stuff&lt;=
X, Xs...&gt; { using type =3D foo&lt;bar&lt;X&gt;, typename do_stuff&lt;Xs.=
...&gt;::type&gt;; };<br>

</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the template parameter list of A and the argument types/kinds=
 of Ts are deduced separately, and conversion potentially occurs when formi=
ng A&lt;Ts...&gt; . No expressiveness is lost versus the &quot;?&quot; synt=
ax because names at the call site are determined to refer to types or objec=
ts independently of the template parameter list, so ? would not pass any in=
formation back to the user anyway.<div>

<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The &#39;auto&#39; keyword would make sense here, but it might make more se=
nse<br>
being restricted to a non-type template parameter (with its type deduced<br=
>
from the template argument). Perhaps it could be made to fill both roles:<b=
r>
</blockquote>
<br></div>
As for the non-type role, that sounds nice as a separate proposal. The stan=
dard explicitly mentions that it&#39;s impossible to pass a non-type argume=
nt and deduce its type, and it makes usage of e.g. std::integral_constant r=
epetitive.</blockquote>

<div><br></div><div>Yes, there&#39;s probably an argument for having both, =
even though there&#39;s a lot of overlap between them.</div><div>=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
=A0 =A0template&lt;auto X&gt; void f() {<br>
=A0 =A0 =A0int a =3D X; // it&#39;s a value by default<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto X&gt; void g() {<br>
=A0 =A0 =A0typename X y; // it can be explicitly treated as a type<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto X&gt; void h() {<br>
=A0 =A0 =A0template X&lt;int&gt; z; // or as a template<br>
=A0 =A0}<br>
=A0 =A0template&lt;auto &amp;X&gt; void i(); // not exactly &#39;auto&#39;,=
 always a non-type<br>
template parameter<br>
<br>
.... though this would require a lot of hacking with the grammar, to allow<b=
r>
&#39;template&#39; and &#39;typename&#39; in these new places.<br>
</blockquote>
<br></div>
Looks like a solution in search of a problem. Every use of the parameter wo=
uld have to be disambiguated, and since the parameter can only refer to the=
 typename or object passed by the caller, each disambiguation would have to=
 go the same way. Might as well keep the status quo.</blockquote>

<div><br></div><div>Uses as a non-type parameter would not need disambiguat=
ion, and it solves both the problem originally raised in this thread and th=
e more-constrained problem raised in the &quot;T for two&quot; section of N=
3405 and the resulting N3601. But I agree that separate syntax for the two =
problems is probably the better choice -- I was just pointing out that it&#=
39;s not the only option.</div>

</div></div></div>
</blockquote></div></div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b86e48259903004ef7eea51--

.

On 1/9/14 8:44 AM, Richard Smith wrote:
> Here's an implementation:
>
>    template<? X> struct is_type : std::false_type {};
>    template<typename T> struct is_type<T> : std::true_type {};

This appears to be using ? like auto, not to mean "type or object."

Also, as you know, class templates cannot currently be overloaded like
this. Functions can be, so:

template< typename >
std::true_type is_type();

template< int > // Insufficient generality, to be fixed by "auto"-like
type deduction.
std::false_type is_type();

template< template< typename ... > class > // Insufficient generality,
to be fixed by "?"-like kind deduction.
std::false_type is_type();

bool three_is_type = decltype( is_type< 3 >() )::value,
     double_is_type = decltype( is_type< double >() )::value,
     vector_is_type = decltype( is_type< std::vector >() )::value;

> Yes, I think the ? extension alone is sufficient for this.
>
> With the addition of some motivating examples, this seems ready to be
> written up as a paper to me. I'm somewhat optimistic that the most
> contentious part of this will be the syntax ('?' or 'auto' or a new keyword
> or something else).

I still don't see the value of an identifier, as opposed to a pack
expansion element, that can be either a type or a value. And such a name
would throw a wrench into template parsing. They could *only* be used as
explicit template arguments to functions as in my example above, or to
template template parameters with "?"-like parameter lists.

If you end up needing to use is_type, you're already in deep shit.

On the other hand, parameter lists are already unpacked using
overloading, or partial specialization which works the same way. This
gives you a branching point to different code paths for type, value, or
template, which can already be written and parsed without redesigning
dependent name lookup.

This is why I think "..." is sufficient with no motivation for "?" or
any provision for a single argument.

--

---
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/.

.

--089e0160cc307a360e04ef808d5c
Content-Type: text/plain; charset=ISO-8859-1

On Wed Jan 08 2014 at 5:28:21 PM, David Krauss <potswa@gmail.com> wrote:

> On 1/9/14 8:44 AM, Richard Smith wrote:
> > Here's an implementation:
> >
> >    template<? X> struct is_type : std::false_type {};
> >    template<typename T> struct is_type<T> : std::true_type {};
>
> This appears to be using ? like auto, not to mean "type or object."
>

No, it's using it to mean "type or object".


> Also, as you know, class templates cannot currently be overloaded like
> this.


It's not an overload, it's a partial specialization.


> Functions can be, so:
>
> template< typename >
> std::true_type is_type();
>
> template< int > // Insufficient generality, to be fixed by "auto"-like
> type deduction.
> std::false_type is_type();
>
> template< template< typename ... > class > // Insufficient generality,
> to be fixed by "?"-like kind deduction.
> std::false_type is_type();
>
> bool three_is_type = decltype( is_type< 3 >() )::value,
>      double_is_type = decltype( is_type< double >() )::value,
>      vector_is_type = decltype( is_type< std::vector >() )::value;
>
> > Yes, I think the ? extension alone is sufficient for this.
> >
> > With the addition of some motivating examples, this seems ready to be
> > written up as a paper to me. I'm somewhat optimistic that the most
> > contentious part of this will be the syntax ('?' or 'auto' or a new
> keyword
> > or something else).
>
> I still don't see the value of an identifier, as opposed to a pack
> expansion element, that can be either a type or a value. And such a name
> would throw a wrench into template parsing. They could *only* be used as
> explicit template arguments to functions as in my example above, or to
> template template parameters with "?"-like parameter lists.
>
> If you end up needing to use is_type, you're already in deep shit.
>
> On the other hand, parameter lists are already unpacked using
> overloading, or partial specialization which works the same way. This
> gives you a branching point to different code paths for type, value, or
> template, which can already be written and parsed without redesigning
> dependent name lookup.
>
> This is why I think "..." is sufficient with no motivation for "?" or
> any provision for a single argument.
>
> --
>
> ---
> 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/.
>

--

---
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/.

--089e0160cc307a360e04ef808d5c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Wed Jan 08 2014 at 5:28:21 PM, David Krauss &lt;<a href=3D"mailto:p=
otswa@gmail.com">potswa@gmail.com</a>&gt; wrote:</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
On 1/9/14 8:44 AM, Richard Smith wrote:<br>
&gt; Here&#39;s an implementation:<br>
&gt;<br>
&gt; =A0 =A0template&lt;? X&gt; struct is_type : std::false_type {};<br>
&gt; =A0 =A0template&lt;typename T&gt; struct is_type&lt;T&gt; : std::true_=
type {};<br>
<br>
This appears to be using ? like auto, not to mean &quot;type or object.&quo=
t;<br></blockquote><div><br></div><div>No, it&#39;s using it to mean &quot;=
type or object&quot;.</div><div>=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Also, as you know, class templates cannot currently be overloaded like<br>
this.</blockquote><div><br></div><div>It&#39;s not an overload, it&#39;s a =
partial specialization.</div><div>=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =
Functions can be, so:<br>

<br>
template&lt; typename &gt;<br>
std::true_type is_type();<br>
<br>
template&lt; int &gt; // Insufficient generality, to be fixed by &quot;auto=
&quot;-like<br>
type deduction.<br>
std::false_type is_type();<br>
<br>
template&lt; template&lt; typename ... &gt; class &gt; // Insufficient gene=
rality,<br>
to be fixed by &quot;?&quot;-like kind deduction.<br>
std::false_type is_type();<br>
<br>
bool three_is_type =3D decltype( is_type&lt; 3 &gt;() )::value,<br>
=A0 =A0 =A0double_is_type =3D decltype( is_type&lt; double &gt;() )::value,=
<br>
=A0 =A0 =A0vector_is_type =3D decltype( is_type&lt; std::vector &gt;() )::v=
alue;<br>
<br>
&gt; Yes, I think the ? extension alone is sufficient for this.<br>
&gt;<br>
&gt; With the addition of some motivating examples, this seems ready to be<=
br>
&gt; written up as a paper to me. I&#39;m somewhat optimistic that the most=
<br>
&gt; contentious part of this will be the syntax (&#39;?&#39; or &#39;auto&=
#39; or a new keyword<br>
&gt; or something else).<br>
<br>
I still don&#39;t see the value of an identifier, as opposed to a pack<br>
expansion element, that can be either a type or a value. And such a name<br=
>
would throw a wrench into template parsing. They could *only* be used as<br=
>
explicit template arguments to functions as in my example above, or to<br>
template template parameters with &quot;?&quot;-like parameter lists.<br>
<br>
If you end up needing to use is_type, you&#39;re already in deep shit.<br>
<br>
On the other hand, parameter lists are already unpacked using<br>
overloading, or partial specialization which works the same way. This<br>
gives you a branching point to different code paths for type, value, or<br>
template, which can already be written and parsed without redesigning<br>
dependent name lookup.<br>
<br>
This is why I think &quot;...&quot; is sufficient with no motivation for &q=
uot;?&quot; or<br>
any provision for a single argument.<br>
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0160cc307a360e04ef808d5c--

.

On 1/9/14 10:41 AM, Richard Smith wrote:
> On Wed Jan 08 2014 at 5:28:21 PM, David Krauss <potswa@gmail.com> wrote:
>
> It's not an overload, it's a partial specialization.

OK, that wasn't clear from the example. So do you intend that an=20
identifier declared with "?" never be used? What could you possibly do=20
with X?

Quoting the previous message:

>> I still don't see the value of an identifier, as opposed to a pack
>> expansion element, that can be either a type or a value. And such a name
>> would throw a wrench into template parsing. They could *only* be used as
>> explicit template arguments to functions as in my example above, or to
>> template template parameters with "?"-like parameter lists.

Edit: You couldn't even use X in these cases, because parse time=20
ambiguity of a template argument is always resolved in favor of a=20
typename ([temp.arg] =A714.3/2).

>> If you end up needing to use is_type, you're already in deep shit.
>>
>> On the other hand, parameter lists are already unpacked using
>> overloading, or partial specialization which works the same way. This
>> gives you a branching point to different code paths for type, value, or
>> template, which can already be written and parsed without redesigning
>> dependent name lookup.
>>
>> This is why I think "..." is sufficient with no motivation for "?" or
>> any provision for a single argument.
>>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--047d7bd6b5b4015a7604ef810f40
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 8, 2014 at 6:54 PM, David Krauss <potswa@gmail.com> wrote:

> On 1/9/14 10:41 AM, Richard Smith wrote:
>
>> On Wed Jan 08 2014 at 5:28:21 PM, David Krauss <potswa@gmail.com> wrote:
>>
>> It's not an overload, it's a partial specialization.
>>
>
> OK, that wasn't clear from the example. So do you intend that an
> identifier declared with "?" never be used? What could you possibly do wi=
th
> X?


You would only be able to use it as a template-argument.


> Quoting the previous message:
>
>  I still don't see the value of an identifier, as opposed to a pack
>>> expansion element, that can be either a type or a value. And such a nam=
e
>>> would throw a wrench into template parsing. They could *only* be used a=
s
>>> explicit template arguments to functions as in my example above, or to
>>> template template parameters with "?"-like parameter lists.
>>>
>>
> Edit: You couldn't even use X in these cases, because parse time ambiguit=
y
> of a template argument is always resolved in favor of a typename
> ([temp.arg] =A714.3/2).


The useful thing about introducing a new feature is that you get to specify
how it works =3D) Naturally, we would specify that passing a generic templa=
te
argument to another template preserves the kind of template argument.


>  If you end up needing to use is_type, you're already in deep shit.
>>>
>>> On the other hand, parameter lists are already unpacked using
>>> overloading, or partial specialization which works the same way. This
>>> gives you a branching point to different code paths for type, value, or
>>> template, which can already be written and parsed without redesigning
>>> dependent name lookup.
>>>
>>> This is why I think "..." is sufficient with no motivation for "?" or
>>> any provision for a single argument.
>>>
>>>
> --
>
> --- 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/.
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--047d7bd6b5b4015a7604ef810f40
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 8, 2014 at 6:54 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 1/9/14 10:41 AM, Richar=
d Smith wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On Wed Jan 08 2014 at 5:28:21 PM, David Krauss &lt;<a href=3D"mailto:potswa=
@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt; wrote:<br>
<br></div><div class=3D"im">
It&#39;s not an overload, it&#39;s a partial specialization.<br>
</div></blockquote>
<br>
OK, that wasn&#39;t clear from the example. So do you intend that an identi=
fier declared with &quot;?&quot; never be used? What could you possibly do =
with X?</blockquote><div><br></div><div>You would only be able to use it as=
 a template-argument.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
Quoting the previous message:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still don&#39;t see the value of an identifier, as opposed to a pack<br>
expansion element, that can be either a type or a value. And such a name<br=
>
would throw a wrench into template parsing. They could *only* be used as<br=
>
explicit template arguments to functions as in my example above, or to<br>
template template parameters with &quot;?&quot;-like parameter lists.<br>
</blockquote></blockquote>
<br></div>
Edit: You couldn&#39;t even use X in these cases, because parse time ambigu=
ity of a template argument is always resolved in favor of a typename ([temp=
..arg] =A714.3/2).</blockquote><div><br></div><div>The useful thing about in=
troducing a new feature is that you get to specify how it works =3D) Natura=
lly, we would specify that passing a generic template argument to another t=
emplate preserves the kind of template argument.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div cla=
ss=3D"h5">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you end up needing to use is_type, you&#39;re already in deep shit.<br>
<br>
On the other hand, parameter lists are already unpacked using<br>
overloading, or partial specialization which works the same way. This<br>
gives you a branching point to different code paths for type, value, or<br>
template, which can already be written and parsed without redesigning<br>
dependent name lookup.<br>
<br>
This is why I think &quot;...&quot; is sufficient with no motivation for &q=
uot;?&quot; or<br>
any provision for a single argument.<br>
<br>
</blockquote></blockquote>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bd6b5b4015a7604ef810f40--

.

On 1/9/14 11:18 AM, Richard Smith wrote:
> The useful thing about introducing a new feature is that you get to specify
> how it works =) Naturally, we would specify that passing a generic template
> argument to another template preserves the kind of template argument.

But how can you make that work without redoing how parsers must classify
type-dependent expressions? And what's the benefit, given that
overloading/partial specialization already solve the problem?

--

---
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/.

.

On 1/10/14 8:11 AM, David Krauss wrote:
> On 1/9/14 11:18 AM, Richard Smith wrote:
>> The useful thing about introducing a new feature is that you get to
>> specify
>> how it works =) Naturally, we would specify that passing a generic
>> template
>> argument to another template preserves the kind of template argument.
>
> But how can you make that work without redoing how parsers must
> classify type-dependent expressions? And what's the benefit, given
> that overloading/partial specialization already solve the problem?

I should be more specific.

Given "?", you can peel off a fully-generic argument from a pack, and
pass it to another template. But the other template must be either
fully-generic, or overloaded/partially specialized. So you might as well
peel the pack in the target overloaded/partially specialized template.
All "?" buys you is the freedom to add a dispatcher between components
which are actually necessary.

I don't see any applications for fully-generic arguments outside
metaprocessing, e.g. of packs. There is no runtime code application
parameterized over all types or all values of any type. For value-like
types, i.e. std::integral_constant, it is idiomatic (and makes perfect
sense) to deal with runtime instances of a stateless class.

--

---
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/.

.

--20cf307c9e1220d0b704ef9359f9
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 9, 2014 at 4:23 PM, David Krauss <potswa@gmail.com> wrote:

> On 1/10/14 8:11 AM, David Krauss wrote:
>
>> On 1/9/14 11:18 AM, Richard Smith wrote:
>>
>>> The useful thing about introducing a new feature is that you get to
>>> specify
>>> how it works =) Naturally, we would specify that passing a generic
>>> template
>>> argument to another template preserves the kind of template argument.
>>>
>>
>> But how can you make that work without redoing how parsers must classify
>> type-dependent expressions? And what's the benefit, given that
>> overloading/partial specialization already solve the problem?
>>
>
> I should be more specific.
>
> Given "?", you can peel off a fully-generic argument from a pack, and pass
> it to another template. But the other template must be either
> fully-generic, or overloaded/partially specialized. So you might as well
> peel the pack in the target overloaded/partially specialized template. All
> "?" buys you is the freedom to add a dispatcher between components which
> are actually necessary.
>

It allows more code reuse, by allowing handling of individual elements of
such a pack to be factored out. That is a valuable property, even if it
only helps those people who are writing template metaprograms.


> I don't see any applications for fully-generic arguments outside
> metaprocessing, e.g. of packs. There is no runtime code application
> parameterized over all types or all values of any type. For value-like
> types, i.e. std::integral_constant, it is idiomatic (and makes perfect
> sense) to deal with runtime instances of a stateless class.

--

---
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/.

--20cf307c9e1220d0b704ef9359f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 9, 2014 at 4:23 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 1/10/14 8:11 AM, David =
Krauss wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 1/9/14 11:18 AM, Richard Smith wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The useful thing about introducing a new feature is that you get to specify=
<br>
how it works =3D) Naturally, we would specify that passing a generic templa=
te<br>
argument to another template preserves the kind of template argument.<br>
</blockquote>
<br>
But how can you make that work without redoing how parsers must classify ty=
pe-dependent expressions? And what&#39;s the benefit, given that overloadin=
g/partial specialization already solve the problem?<br>
</blockquote>
<br></div>
I should be more specific.<br>
<br>
Given &quot;?&quot;, you can peel off a fully-generic argument from a pack,=
 and pass it to another template. But the other template must be either ful=
ly-generic, or overloaded/partially specialized. So you might as well peel =
the pack in the target overloaded/partially specialized template. All &quot=
;?&quot; buys you is the freedom to add a dispatcher between components whi=
ch are actually necessary.<br>
</blockquote><div><br></div><div>It allows more code reuse, by allowing han=
dling of individual elements of such a pack to be factored out. That is a v=
aluable property, even if it only helps those people who are writing templa=
te metaprograms.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
I don&#39;t see any applications for fully-generic arguments outside metapr=
ocessing, e.g. of packs. There is no runtime code application parameterized=
 over all types or all values of any type. For value-like types, i.e. std::=
integral_constant, it is idiomatic (and makes perfect sense) to deal with r=
untime instances of a stateless class.</blockquote>
</div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--20cf307c9e1220d0b704ef9359f9--

.

On 1/10/14 9:07 AM, Richard Smith wrote:
> On Thu, Jan 9, 2014 at 4:23 PM, David Krauss <potswa@gmail.com> wrote:
>
>> On 1/10/14 8:11 AM, David Krauss wrote:
>>
>> Given "?", you can peel off a fully-generic argument from a pack, and
>> pass it to another template. But the other template must be either
>> fully-generic, or overloaded/partially specialized. So you might as
>> well peel the pack in the target overloaded/partially specialized
>> template. All "?" buys you is the freedom to add a dispatcher between
>> components which are actually necessary.
> It allows more code reuse, by allowing handling of individual elements of
> such a pack to be factored out. That is a valuable property, even if it
> only helps those people who are writing template metaprograms.

I'm still skeptical that real factoring is ever possible, i.e. that a
template with a fully generic non-pack parameter, and doing more than
forward it (which could be done by a tuple-like, pack-based utility),
can ever usefully be more than a simple dispatcher. This refers to the
primary template, not the specializations. Your previous example use
case did not actually use the fully-generic single argument at all, and
might as well have taken a pack:

   template< ... > struct is_type : std::false_type {}; // primary
   template<typename T> struct is_type<T> : std::true_type {}; // partial specialization


This is assuming, as the previous example already did, that "typename"
is more specialized than fully-generic. Presumably "<typename>" is still
never more specialized than "<typename ...>". We can remove that
assumption, and contain the pattern making it scalable by adding that
tuple-like utility:

   template< ... > struct generic_tuple; // library utility

   template< typename > struct is_type : std::false_type {}; // primary
   template<typename T> struct is_type< generic_tuple< T > > : std::true_type {}; // partial specialization


The user would have no need for an is_type facility, though, because
peeling a tuple element would always require type/value resolution.

Prototyping and practice will tell. But, let's keep an eye out for
unnecessary complexity masquerading as factoring.

--

---
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/.

.

------=_Part_148_30962611.1389348092038
Content-Type: text/plain; charset=ISO-8859-1

Except that it is error prone I like your idea:

   template< ... > struct is_type : std::false_type {}; // primary
   template<typename T> struct is_type<T> : std::true_type {}; // partial
specialization

(error prone in the sense that if you call it with more than one type it
tells you it isn't a type).

But in our use case we would first have to split the incoming generic pack
into its individual elements to be able to test them for type/non-type. Can
this be done with only the ... feature. I think it can, but only given the
other "auto" feature. I exemplify by a simple function to get info about
the first element of a generic pack:

   template<...> struct HeadInfo;
   template<typename T, ...> struct HeadInfo<T, ...> {
       static const bool is_type = true;
       typedef T type;
   };
   template<auto V, ...> struct HeadInfo<V, ...> {
       static const bool is_type = false;
       typedef decltype(V) type;
       static const auto value = V;
   };

Well, now that I wrote the code I noticed that the same "default based"
technique used for is_type is usable here too, except of course that you
would not get the type and value members for the non typename case. Also,
it seems that it gets hard to work with the "always variadic" nature of the
resulting templates, for instance we could not write static const bool
is_type = std::is_type<...> here as it would be exposed to the
error-proneness I described at the top of this post.

My conclusion for now is that if we have 'auto' as I used it above we only
need the ... notation for variadic generic parameters, as auto and typename
can be used to differentiate the members of the generic pack as shown in
the HeadInfo example. Thus a new implementation of is_type is like this:

 template< ... > struct is_type; // primary, not implemented. This prevents
using is_type with more than one element packs.
 template<auto V> : struct is_type<V> : std::false_type {};
 template<typename T> struct is_type<T> : std::true_type {}; // partial
specialization

The only problem I see with this is that it is kind of weird to define the
primary template with ... which denotes any number of anything. At least
error messages when you instantiate with more than one parameter will be
misleading, as it will complain about the class being incomplete rather
than the template parameters being too many. This argument alone seems
however to be too weak to motivate a ? feature.




Den fredagen den 10:e januari 2014 kl. 02:32:48 UTC+1 skrev David Krauss:
>
> On 1/10/14 9:07 AM, Richard Smith wrote:
> > On Thu, Jan 9, 2014 at 4:23 PM, David Krauss <pot...@gmail.com<javascript:>>
> wrote:
> >
> >> On 1/10/14 8:11 AM, David Krauss wrote:
> >>
> >> Given "?", you can peel off a fully-generic argument from a pack, and
> >> pass it to another template. But the other template must be either
> >> fully-generic, or overloaded/partially specialized. So you might as
> >> well peel the pack in the target overloaded/partially specialized
> >> template. All "?" buys you is the freedom to add a dispatcher between
> >> components which are actually necessary.
> > It allows more code reuse, by allowing handling of individual elements
> of
> > such a pack to be factored out. That is a valuable property, even if it
> > only helps those people who are writing template metaprograms.
>
> I'm still skeptical that real factoring is ever possible, i.e. that a
> template with a fully generic non-pack parameter, and doing more than
> forward it (which could be done by a tuple-like, pack-based utility),
> can ever usefully be more than a simple dispatcher. This refers to the
> primary template, not the specializations. Your previous example use
> case did not actually use the fully-generic single argument at all, and
> might as well have taken a pack:
>
>    template< ... > struct is_type : std::false_type {}; // primary
>    template<typename T> struct is_type<T> : std::true_type {}; // partial
> specialization
>
>
> This is assuming, as the previous example already did, that "typename"
> is more specialized than fully-generic. Presumably "<typename>" is still
> never more specialized than "<typename ...>". We can remove that
> assumption, and contain the pattern making it scalable by adding that
> tuple-like utility:
>
>    template< ... > struct generic_tuple; // library utility
>
>    template< typename > struct is_type : std::false_type {}; // primary
>    template<typename T> struct is_type< generic_tuple< T > > :
> std::true_type {}; // partial specialization
>
>
> The user would have no need for an is_type facility, though, because
> peeling a tuple element would always require type/value resolution.
>
> Prototyping and practice will tell. But, let's keep an eye out for
> unnecessary complexity masquerading as factoring.
>
>

--

---
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/.

------=_Part_148_30962611.1389348092038
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Except that it is error prone I like your idea:<div><br></=
div><div>&nbsp; &nbsp;template&lt; ... &gt; struct is_type : std::false_typ=
e {}; // primary&nbsp;<br>&nbsp; &nbsp;template&lt;typename T&gt; struct is=
_type&lt;T&gt; : std::true_type {}; // partial specialization&nbsp;<br><br>=
(error prone in the sense that if you call it with more than one type it te=
lls you it isn't a type).</div><div><br></div><div>But in our use case we w=
ould first have to split the incoming generic pack into its individual elem=
ents to be able to test them for type/non-type. Can this be done with only =
the ... feature. I think it can, but only given the other "auto" feature. I=
 exemplify by a simple function to get info about the first element of a ge=
neric pack:</div><div><br></div><div>&nbsp; &nbsp;template&lt;...&gt; struc=
t HeadInfo;</div><div>&nbsp; &nbsp;template&lt;typename T, ...&gt; struct H=
eadInfo&lt;T, ...&gt; {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const b=
ool is_type =3D true;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;typedef T type;<=
/div><div>&nbsp; &nbsp;};</div><div>&nbsp; &nbsp;template&lt;auto V, ...&gt=
; struct HeadInfo&lt;V, ...&gt; {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;stat=
ic const bool is_type =3D false;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;typed=
ef decltype(V) type;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const auto=
 value =3D V;</div><div>&nbsp; &nbsp;};</div><div><br></div><div>Well, now =
that I wrote the code I noticed that the same "default based" technique use=
d for is_type is usable here too, except of course that you would not get t=
he type and value members for the non typename case. Also, it seems that it=
 gets hard to work with the "always variadic" nature of the resulting templ=
ates, for instance we could not write static const bool is_type =3D std::is=
_type&lt;...&gt; here as it would be exposed to the error-proneness I descr=
ibed at the top of this post.</div><div><br></div><div>My conclusion for no=
w is that if we have 'auto' as I used it above we only need the ... notatio=
n for variadic generic parameters, as auto and typename can be used to diff=
erentiate the members of the generic pack as shown in the HeadInfo example.=
 Thus a new implementation of is_type is like this:</div><div><br></div><di=
v>&nbsp;template&lt; ... &gt; struct is_type;&nbsp;// primary, not implemen=
ted. This prevents using is_type with more than one element packs.</div><di=
v>&nbsp;template&lt;auto V&gt; : struct is_type&lt;V&gt; : std::false_type =
{};<br>&nbsp;template&lt;typename T&gt; struct is_type&lt;T&gt; : std::true=
_type {}; // partial specialization&nbsp;<br></div><div><br></div><div>The =
only problem I see with this is that it is kind of weird to define the prim=
ary template with ... which denotes any number of anything. At least error =
messages when you instantiate with more than one parameter will be misleadi=
ng, as it will complain about the class being incomplete rather than the te=
mplate parameters being too many. This argument alone seems however to be t=
oo weak to motivate a ? feature.</div><div><br></div><div><br></div><div><b=
r></div><div><br>Den fredagen den 10:e januari 2014 kl. 02:32:48 UTC+1 skre=
v David Krauss:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1/10/14 9:07=
 AM, Richard Smith wrote:
<br>&gt; On Thu, Jan 9, 2014 at 4:23 PM, David Krauss &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"0fqkxdVnXzcJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; On 1/10/14 8:11 AM, David Krauss wrote:
<br>&gt;&gt;
<br>&gt;&gt; Given "?", you can peel off a fully-generic argument from a pa=
ck, and=20
<br>&gt;&gt; pass it to another template. But the other template must be ei=
ther=20
<br>&gt;&gt; fully-generic, or overloaded/partially specialized. So you mig=
ht as=20
<br>&gt;&gt; well peel the pack in the target overloaded/partially speciali=
zed=20
<br>&gt;&gt; template. All "?" buys you is the freedom to add a dispatcher =
between=20
<br>&gt;&gt; components which are actually necessary.=20
<br>&gt; It allows more code reuse, by allowing handling of individual elem=
ents of
<br>&gt; such a pack to be factored out. That is a valuable property, even =
if it
<br>&gt; only helps those people who are writing template metaprograms.
<br>
<br>I'm still skeptical that real factoring is ever possible, i.e. that a=
=20
<br>template with a fully generic non-pack parameter, and doing more than=
=20
<br>forward it (which could be done by a tuple-like, pack-based utility),=
=20
<br>can ever usefully be more than a simple dispatcher. This refers to the=
=20
<br>primary template, not the specializations. Your previous example use=20
<br>case did not actually use the fully-generic single argument at all, and=
=20
<br>might as well have taken a pack:
<br>
<br>&nbsp; &nbsp;template&lt; ... &gt; struct is_type : std::false_type {};=
 // primary
<br>&nbsp; &nbsp;template&lt;typename T&gt; struct is_type&lt;T&gt; : std::=
true_type {}; // partial specialization
<br>
<br>
<br>This is assuming, as the previous example already did, that "typename"=
=20
<br>is more specialized than fully-generic. Presumably "&lt;typename&gt;" i=
s still=20
<br>never more specialized than "&lt;typename ...&gt;". We can remove that=
=20
<br>assumption, and contain the pattern making it scalable by adding that=
=20
<br>tuple-like utility:
<br>
<br>&nbsp; &nbsp;template&lt; ... &gt; struct generic_tuple; // library uti=
lity
<br>
<br>&nbsp; &nbsp;template&lt; typename &gt; struct is_type : std::false_typ=
e {}; // primary
<br>&nbsp; &nbsp;template&lt;typename T&gt; struct is_type&lt; generic_tupl=
e&lt; T &gt; &gt; : std::true_type {}; // partial specialization
<br>
<br>
<br>The user would have no need for an is_type facility, though, because=20
<br>peeling a tuple element would always require type/value resolution.
<br>
<br>Prototyping and practice will tell. But, let's keep an eye out for=20
<br>unnecessary complexity masquerading as factoring.
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_148_30962611.1389348092038--

.

------=_Part_349_5201527.1389368115307
Content-Type: text/plain; charset=ISO-8859-1

On Friday, January 10, 2014 5:01:31 AM UTC-5, Bengt Gustafsson wrote:

>
>    template<...> struct HeadInfo;
>    template<typename T, ...> struct HeadInfo<T, ...> {
>        static const bool is_type = true;
>        typedef T type;
>    };
>    template<auto V, ...> struct HeadInfo<V, ...> {
>        static const bool is_type = false;
>        typedef decltype(V) type;
>        static const auto value = V;
>    };
>
>

That syntax without ? would still require being able to name the generic
pack. Your example should be:


template<typename T, ...*Tail*> struct HeadInfo<T, *Tail*...> {
static const bool is_type = true;
typedef T type;
};



Giving a name would be required to disambiguate cases where there is more
than one generic pack:


template <...> struct A {};

template <class T, class U>
struct B;

template <...ElemsT, ...ElemsU>
struct B<A<ElemsT...>, A<ElemsU...>>
{
};


As for actual use cases (with or without ?), there is more
than metaprogramming refactoring sugar. I can see at least one case that it
would allow to fix which is boost recursive variants:
*http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html*<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html>
Unless I'm wrong, recursive variants currently cannot contain a template
type with non-type parameters, which is a bit annoying. This feature would
make it possible.

--

---
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/.

------=_Part_349_5201527.1389368115307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Friday, January 10, 2014 5:01:31 AM UTC-5, Bengt G=
ustafsson wrote:</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div>&n=
bsp;</div><div>&nbsp; &nbsp;template&lt;...&gt; struct HeadInfo;</div><div>=
&nbsp; &nbsp;template&lt;typename T, ...&gt; struct HeadInfo&lt;T, ...&gt; =
{</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const bool is_type =3D true;<=
/div><div>&nbsp; &nbsp; &nbsp; &nbsp;typedef T type;</div><div>&nbsp; &nbsp=
;};</div><div>&nbsp; &nbsp;template&lt;auto V, ...&gt; struct HeadInfo&lt;V=
, ...&gt; {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const bool is_type =
=3D false;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;typedef decltype(V) type;</=
div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const auto value =3D V;</div><di=
v>&nbsp; &nbsp;};</div><div>&nbsp;</div></div></blockquote><div>&nbsp;</div=
><div>That syntax without ? would still require being able to name the gene=
ric pack. Your example should be:</div><div>&nbsp;</div><blockquote style=
=3D"margin-right: 0px;" dir=3D"ltr"><div><font face=3D"courier new,monospac=
e">template&lt;typename T, ...<strong><font color=3D"#ff0000">Tail</font></=
strong>&gt; struct HeadInfo&lt;T, <strong><font color=3D"#ff0000">Tail</fon=
t></strong>...&gt; {</font></div><div><font face=3D"courier new,monospace">=
       static const bool is_type =3D true;</font></div><div><font face=3D"c=
ourier new,monospace">       typedef T type;</font></div><div><font face=3D=
"courier new,monospace">   };</font></div></blockquote><div>&nbsp;</div><di=
v>&nbsp;</div><div>Giving a name would be required to disambiguate cases wh=
ere there is more than one generic pack:</div><div>&nbsp;</div><blockquote =
style=3D"margin-right: 0px;" dir=3D"ltr"><div><font face=3D"courier new,mon=
ospace">template &lt;...&gt; struct A {};</font></div><div><font face=3D"co=
urier new,monospace"></font>&nbsp;</div><div><font face=3D"courier new,mono=
space">template &lt;class T, class U&gt;</font></div><div><font face=3D"cou=
rier new,monospace">struct B;</font></div><div><font face=3D"courier new,mo=
nospace"></font>&nbsp;</div><div><font face=3D"courier new,monospace">templ=
ate &lt;...ElemsT, ...ElemsU&gt;</font></div><div><font face=3D"courier new=
,monospace">struct B&lt;A&lt;ElemsT...&gt;, A&lt;ElemsU...&gt;&gt;</font></=
div><div><font face=3D"courier new,monospace">{</font></div><div><font face=
=3D"courier new,monospace">};</font></div></blockquote><div>&nbsp;</div><di=
v>As for actual use cases (with or without ?),&nbsp;there is more than&nbsp=
;metaprogramming refactoring sugar.&nbsp;I can see at least one case&nbsp;t=
hat it would allow to fix which is boost recursive variants:</div><div><a h=
ref=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_v=
ariant.html"><u><font color=3D"#0066cc">http://www.boost.org/doc/libs/1_55_=
0/doc/html/boost/make_recursive_variant.html</font></u></a></div><div>Unles=
s I'm wrong, recursive variants currently cannot contain a template type wi=
th non-type parameters, which is a bit annoying.&nbsp;This feature would ma=
ke it possible.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_349_5201527.1389368115307--

.

------=_Part_613_1796018.1389397299857
Content-Type: text/plain; charset=ISO-8859-1

Yes, you are absolutely right, the "Tail" should have been there in my
example just as you wrote it.

So it seems right now that we can make do with the ... "generic pack" type
and auto, but it bugs me a bit that we now have all of these forms of a
template parameter type (where int is of course just an example):

int                  One template parameter of type int
int...               Any number of int template parameters
auto               One non-type template parameter of any type
auto...            Any number of non-type template parameters of mixed
types*
typename       One type template parameter
typename...    Any number of type template parameters
....                  Any number of type or non-type template parameters

But not:
?                   One type or auto tempalte parameter  (apart from the
bikeshed issue of ?)


At least from an educational standpoint it could be wise to be more
orthogonal, which would also mean to reintroduce ?... instead of just ...

Another risk I see with using ... is that people will start to over-use it
because it looks nice, i.e. writing template<...> for a variadic template
template parameter even when the code only handles that the actuals are
types.

In the back of my head I also feel that sooner of later we will find
something that can't be done due to the omission of the lonely ? feature.

Entering the bikeshed I toyed with the use of . instead of ? It kind of
goes nicely with ... as it would be interpreted as "many dots". The main
problem could be that it is almost invisible on the screen especially as a
typical usage would be template<. H,... T>. The * suggested in this thread
is a bit scary as you can also write for instance template<int*...> which
as another traditional meaning...  I also scanned the keyword list but
didn't find any real candidates.

BTW: I can't seem to find any wording in the standard document (C++14) that
allows for instance a function taking any number of ints, although I have
seen uses of it in this list (and which I assumed was available in my list
above):

template<int... dims> class Matrix;

VS2012 also does not allow this. What is the status?

* The reason for assuming that auto... would refer to any number of
parameters of different types is that otherwise reursive decomposition like
this would be strange:

template<auto H, auto... Ts> class Foo;

as now H is "another auto" than Ts which can bind to another type, while
the Ts must still be the same, untill next recursion step.

Is there a paper or thread for auto template parameters?


Den fredagen den 10:e januari 2014 kl. 16:35:15 UTC+1 skrev Alex B:
>
> On Friday, January 10, 2014 5:01:31 AM UTC-5, Bengt Gustafsson wrote:
>
>>
>>    template<...> struct HeadInfo;
>>    template<typename T, ...> struct HeadInfo<T, ...> {
>>        static const bool is_type = true;
>>        typedef T type;
>>    };
>>    template<auto V, ...> struct HeadInfo<V, ...> {
>>        static const bool is_type = false;
>>        typedef decltype(V) type;
>>        static const auto value = V;
>>    };
>>
>>
>
> That syntax without ? would still require being able to name the generic
> pack. Your example should be:
>
>
> template<typename T, ...*Tail*> struct HeadInfo<T, *Tail*...> {
> static const bool is_type = true;
> typedef T type;
> };
>
>
>
> Giving a name would be required to disambiguate cases where there is more
> than one generic pack:
>
>
> template <...> struct A {};
>
> template <class T, class U>
> struct B;
>
> template <...ElemsT, ...ElemsU>
> struct B<A<ElemsT...>, A<ElemsU...>>
> {
> };
>
>
> As for actual use cases (with or without ?), there is more
> than metaprogramming refactoring sugar. I can see at least one case that it
> would allow to fix which is boost recursive variants:
>
> *http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html*<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html>
> Unless I'm wrong, recursive variants currently cannot contain a template
> type with non-type parameters, which is a bit annoying. This feature would
> make it possible.
>

--

---
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/.

------=_Part_613_1796018.1389397299857
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, you are absolutely right, the "Tail" should have been=
 there in my example just as you wrote it.<div><br></div><div>So it seems r=
ight now that we can make do with the ... "generic pack" type and auto, but=
 it bugs me a bit that we now have all of these forms of a template paramet=
er type (where int is of course just an example):</div><div><br></div><div>=
int &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;One templ=
ate parameter of type int</div><div>int... &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; Any number of int template parameters</div><div>auto &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; One non-type template parameter=
 of any type</div><div>auto... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Any=
 number of non-type template parameters of mixed types*</div><div>typename =
&nbsp; &nbsp; &nbsp; One type template parameter</div><div>typename... &nbs=
p; &nbsp;Any number of type template parameters</div><div>... &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Any number of type or non-=
type template parameters</div><div><br></div><div>But not:</div><div>? &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; One type or auto=
 tempalte parameter &nbsp;(apart from the bikeshed issue of ?)</div><div><b=
r></div><div><br></div><div>At least from an educational standpoint it coul=
d be wise to be more orthogonal, which would also mean to reintroduce ?... =
instead of just ...</div><div><br></div><div>Another risk I see with using =
.... is that people will start to over-use it because it looks nice, i.e. wr=
iting template&lt;...&gt; for a variadic template template parameter even w=
hen the code only handles that the actuals are types.</div><div><br></div><=
div>In the back of my head I also feel that sooner of later we will find so=
mething that can't be done due to the omission of the lonely ? feature.</di=
v><div><br></div><div>Entering the bikeshed I toyed with the use of . inste=
ad of ? It kind of goes nicely with ... as it would be interpreted as "many=
 dots". The main problem could be that it is almost invisible on the screen=
 especially as a typical usage would be template&lt;. H,... T&gt;. The * su=
ggested in this thread is a bit scary as you can also write for instance te=
mplate&lt;int*...&gt; which as another traditional meaning... &nbsp;I also =
scanned the keyword list but didn't find any real candidates.</div><div><br=
></div><div>BTW: I can't seem to find any wording in the standard document =
(C++14) that allows for instance a function taking any number of ints, alth=
ough I have seen uses of it in this list (and which I assumed was available=
 in my list above):</div><div><br></div><div>template&lt;int... dims&gt; cl=
ass Matrix;&nbsp;</div><div><br></div><div>VS2012 also does not allow this.=
 What is the status?&nbsp;</div><div><br></div><div>* The reason for assumi=
ng that auto... would refer to any number of parameters of different types =
is that otherwise reursive decomposition like this would be strange:</div><=
div><br></div><div>template&lt;auto H, auto... Ts&gt; class Foo;</div><div>=
<br></div><div>as now H is "another auto" than Ts which can bind to another=
 type, while the Ts must still be the same, untill next recursion step.</di=
v><div><br></div><div>Is there a paper or thread for auto template paramete=
rs?</div><div><br></div><div><br></div><div>Den fredagen den 10:e januari 2=
014 kl. 16:35:15 UTC+1 skrev Alex B:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>On Friday, January 10, 2014 5:01:31 AM UTC-5, B=
engt Gustafsson wrote:</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid" class=3D"gmail_quote"><div dir=3D"ltr"><div>&nbsp;</=
div><div>&nbsp; &nbsp;template&lt;...&gt; struct HeadInfo;</div><div>&nbsp;=
 &nbsp;template&lt;typename T, ...&gt; struct HeadInfo&lt;T, ...&gt; {</div=
><div>&nbsp; &nbsp; &nbsp; &nbsp;static const bool is_type =3D true;</div><=
div>&nbsp; &nbsp; &nbsp; &nbsp;typedef T type;</div><div>&nbsp; &nbsp;};</d=
iv><div>&nbsp; &nbsp;template&lt;auto V, ...&gt; struct HeadInfo&lt;V, ...&=
gt; {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;static const bool is_type =3D fa=
lse;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;typedef decltype(V) type;</div><d=
iv>&nbsp; &nbsp; &nbsp; &nbsp;static const auto value =3D V;</div><div>&nbs=
p; &nbsp;};</div><div>&nbsp;</div></div></blockquote><div>&nbsp;</div><div>=
That syntax without ? would still require being able to name the generic pa=
ck. Your example should be:</div><div>&nbsp;</div><blockquote style=3D"marg=
in-right:0px" dir=3D"ltr"><div><font face=3D"courier new,monospace">templat=
e&lt;typename T, ...<strong><font color=3D"#ff0000">Tail</font></strong>&gt=
; struct HeadInfo&lt;T, <strong><font color=3D"#ff0000">Tail</font></strong=
>...&gt; {</font></div><div><font face=3D"courier new,monospace">       sta=
tic const bool is_type =3D true;</font></div><div><font face=3D"courier new=
,monospace">       typedef T type;</font></div><div><font face=3D"courier n=
ew,monospace">   };</font></div></blockquote><div>&nbsp;</div><div>&nbsp;</=
div><div>Giving a name would be required to disambiguate cases where there =
is more than one generic pack:</div><div>&nbsp;</div><blockquote style=3D"m=
argin-right:0px" dir=3D"ltr"><div><font face=3D"courier new,monospace">temp=
late &lt;...&gt; struct A {};</font></div><div><font face=3D"courier new,mo=
nospace"></font>&nbsp;</div><div><font face=3D"courier new,monospace">templ=
ate &lt;class T, class U&gt;</font></div><div><font face=3D"courier new,mon=
ospace">struct B;</font></div><div><font face=3D"courier new,monospace"></f=
ont>&nbsp;</div><div><font face=3D"courier new,monospace">template &lt;...E=
lemsT, ...ElemsU&gt;</font></div><div><font face=3D"courier new,monospace">=
struct B&lt;A&lt;ElemsT...&gt;, A&lt;ElemsU...&gt;&gt;</font></div><div><fo=
nt face=3D"courier new,monospace">{</font></div><div><font face=3D"courier =
new,monospace">};</font></div></blockquote><div>&nbsp;</div><div>As for act=
ual use cases (with or without ?),&nbsp;there is more than&nbsp;metaprogram=
ming refactoring sugar.&nbsp;I can see at least one case&nbsp;that it would=
 allow to fix which is boost recursive variants:</div><div><a href=3D"http:=
//www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html"=
 target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2Fdoc%2Fhtml%2Fboost%2Fm=
ake_recursive_variant.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEkLx7NjbgeN_C=
2OWEwhZAKDITriQ';return true;" onclick=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2Fdoc%2Fhtml%2Fb=
oost%2Fmake_recursive_variant.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEkLx7=
NjbgeN_C2OWEwhZAKDITriQ';return true;"><u><font color=3D"#0066cc">http://ww=
w.boost.org/doc/libs/<wbr>1_55_0/doc/html/boost/make_<wbr>recursive_variant=
..html</font></u></a></div><div>Unless I'm wrong, recursive variants current=
ly cannot contain a template type with non-type parameters, which is a bit =
annoying.&nbsp;This feature would make it possible.</div></div></blockquote=
></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_613_1796018.1389397299857--

.

--bcaec5485ad06dfd2e04efa7211e
Content-Type: text/plain; charset=ISO-8859-1

On Fri Jan 10 2014 at 3:41:44 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> Yes, you are absolutely right, the "Tail" should have been there in my
> example just as you wrote it.
>
> So it seems right now that we can make do with the ... "generic pack" type
> and auto, but it bugs me a bit that we now have all of these forms of a
> template parameter type (where int is of course just an example):
>
> int                  One template parameter of type int
> int...               Any number of int template parameters
> auto               One non-type template parameter of any type
> auto...            Any number of non-type template parameters of mixed
> types*
> typename       One type template parameter
> typename...    Any number of type template parameters
>

Also:

template<template-parameter-list> class
template<template-parameter-list> class...


> ...                  Any number of type or non-type template parameters
>
> But not:
> ?                   One type or auto tempalte parameter  (apart from the
> bikeshed issue of ?)
>
>
> At least from an educational standpoint it could be wise to be more
> orthogonal, which would also mean to reintroduce ?... instead of just ...
>
> Another risk I see with using ... is that people will start to over-use it
> because it looks nice, i.e. writing template<...> for a variadic template
> template parameter even when the code only handles that the actuals are
> types.
>
> In the back of my head I also feel that sooner of later we will find
> something that can't be done due to the omission of the lonely ? feature.
>
> Entering the bikeshed I toyed with the use of . instead of ? It kind of
> goes nicely with ... as it would be interpreted as "many dots". The main
> problem could be that it is almost invisible on the screen especially as a
> typical usage would be template<. H,... T>. The * suggested in this thread
> is a bit scary as you can also write for instance template<int*...> which
> as another traditional meaning...  I also scanned the keyword list but
> didn't find any real candidates.
>

Yes, I also scanned the keyword list before suggesting '?'. The only
plausible candidate there was 'auto', but that makes more sense as a
generic non-type template parameter. '?' doesn't seem like a great name to
me, but it at least gives us something to talk about for now. Hopefully
someone can find something better. '.' versus '...' seems cute, but perhaps
it's too cute, and as you say, the dot is easily missed.

BTW: I can't seem to find any wording in the standard document (C++14) that
> allows for instance a function taking any number of ints, although I have
> seen uses of it in this list (and which I assumed was available in my list
> above):
>
> template<int... dims> class Matrix;
>
> VS2012 also does not allow this. What is the status?
>

This is valid in C++11. We have:

14.1/1:
  template-parameter:
    type-parameter
    parameter-declaration

Per 8.3.5, 'int... dims' is a parameter-declaration. Per 14.1/15, such a
template-parameter declares a parameter pack.


> * The reason for assuming that auto... would refer to any number of
> parameters of different types is that otherwise reursive decomposition like
> this would be strange:
>
> template<auto H, auto... Ts> class Foo;
>
> as now H is "another auto" than Ts which can bind to another type, while
> the Ts must still be the same, untill next recursion step.
>
> Is there a paper or thread for auto template parameters?
>

No, it came up during discussion of N3601 at the Bristol WG21 meeting, but
I don't believe there's any paper on it. (And at Bristol, EWG was pretty
evenly divided between wanting N3601's syntax and wanting 'auto'.)


> Den fredagen den 10:e januari 2014 kl. 16:35:15 UTC+1 skrev Alex B:
>
> On Friday, January 10, 2014 5:01:31 AM UTC-5, Bengt Gustafsson wrote:
>
>
>    template<...> struct HeadInfo;
>    template<typename T, ...> struct HeadInfo<T, ...> {
>        static const bool is_type = true;
>        typedef T type;
>    };
>    template<auto V, ...> struct HeadInfo<V, ...> {
>        static const bool is_type = false;
>        typedef decltype(V) type;
>        static const auto value = V;
>    };
>
>
>
> That syntax without ? would still require being able to name the generic
> pack. Your example should be:
>
>
> template<typename T, ...*Tail*> struct HeadInfo<T, *Tail*...> {
> static const bool is_type = true;
> typedef T type;
> };
>
>
>
> Giving a name would be required to disambiguate cases where there is more
> than one generic pack:
>
>
> template <...> struct A {};
>
> template <class T, class U>
> struct B;
>
> template <...ElemsT, ...ElemsU>
> struct B<A<ElemsT...>, A<ElemsU...>>
> {
> };
>
>
> As for actual use cases (with or without ?), there is more
> than metaprogramming refactoring sugar. I can see at least one case that it
> would allow to fix which is boost recursive variants:
>
> *http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html*<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html>
> Unless I'm wrong, recursive variants currently cannot contain a template
> type with non-type parameters, which is a bit annoying. This feature would
> make it possible.
>
>  --
>
> ---
> 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/.
>

--

---
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/.

--bcaec5485ad06dfd2e04efa7211e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Fri Jan 10 2014 at 3:41:44 PM, Bengt Gustafsson &lt;<a href=3D"mail=
to:bengt.gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>&gt; wro=
te:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Yes, you are absolutely right, the &quot;Tail&quot; should=
 have been there in my example just as you wrote it.<div><br></div><div>So =
it seems right now that we can make do with the ... &quot;generic pack&quot=
; type and auto, but it bugs me a bit that we now have all of these forms o=
f a template parameter type (where int is of course just an example):</div>
<div><br></div><div>int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0One template par=
ameter of type int</div><div>int... =A0 =A0 =A0 =A0 =A0 =A0 =A0 Any number =
of int template parameters</div><div>auto =A0 =A0 =A0 =A0 =A0 =A0 =A0 One n=
on-type template parameter of any type</div>
<div>auto... =A0 =A0 =A0 =A0 =A0 =A0Any number of non-type template paramet=
ers of mixed types*</div><div>typename =A0 =A0 =A0 One type template parame=
ter</div><div>typename... =A0 =A0Any number of type template parameters</di=
v></div></blockquote>
<div><br></div><div>Also:</div><div><br></div><div>template&lt;template-par=
ameter-list&gt; class<br></div><div>template&lt;template-parameter-list&gt;=
 class...</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Any number of =
type or non-type template parameters</div><div><br></div><div>But not:</div=
><div>? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 One type or auto tempalte param=
eter =A0(apart from the bikeshed issue of ?)</div>
<div><br></div><div><br></div><div>At least from an educational standpoint =
it could be wise to be more orthogonal, which would also mean to reintroduc=
e ?... instead of just ...</div><div><br></div><div>Another risk I see with=
 using ... is that people will start to over-use it because it looks nice, =
i.e. writing template&lt;...&gt; for a variadic template template parameter=
 even when the code only handles that the actuals are types.</div>
<div><br></div><div>In the back of my head I also feel that sooner of later=
 we will find something that can&#39;t be done due to the omission of the l=
onely ? feature.</div><div><br></div><div>Entering the bikeshed I toyed wit=
h the use of . instead of ? It kind of goes nicely with ... as it would be =
interpreted as &quot;many dots&quot;. The main problem could be that it is =
almost invisible on the screen especially as a typical usage would be templ=
ate&lt;. H,... T&gt;. The * suggested in this thread is a bit scary as you =
can also write for instance template&lt;int*...&gt; which as another tradit=
ional meaning... =A0I also scanned the keyword list but didn&#39;t find any=
 real candidates.</div>
</div></blockquote><div><br></div><div>Yes, I also scanned the keyword list=
 before suggesting &#39;?&#39;. The only plausible candidate there was &#39=
;auto&#39;, but that makes more sense as a generic non-type template parame=
ter. &#39;?&#39; doesn&#39;t seem like a great name to me, but it at least =
gives us something to talk about for now. Hopefully someone can find someth=
ing better. &#39;.&#39; versus &#39;...&#39; seems cute, but perhaps it&#39=
;s too cute, and as you say, the dot is easily missed.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>BTW: I =
can&#39;t seem to find any wording in the standard document (C++14) that al=
lows for instance a function taking any number of ints, although I have see=
n uses of it in this list (and which I assumed was available in my list abo=
ve):</div>
<div><br></div><div>template&lt;int... dims&gt; class Matrix;=A0</div><div>=
<br></div><div>VS2012 also does not allow this. What is the status?=A0</div=
></div></blockquote><div><br></div><div>This is valid in C++11. We have:</d=
iv>
<div><br></div><div>14.1/1:</div><div>=A0 template-parameter:</div><div>=A0=
 =A0 type-parameter</div><div>=A0 =A0 parameter-declaration</div><div><br><=
/div><div>Per 8.3.5, &#39;int... dims&#39; is a parameter-declaration. Per =
14.1/15, such a template-parameter declares a parameter pack.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>* The re=
ason for assuming that auto... would refer to any number of parameters of d=
ifferent types is that otherwise reursive decomposition like this would be =
strange:</div>
<div><br></div><div>template&lt;auto H, auto... Ts&gt; class Foo;</div><div=
><br></div><div>as now H is &quot;another auto&quot; than Ts which can bind=
 to another type, while the Ts must still be the same, untill next recursio=
n step.</div>
<div><br></div><div>Is there a paper or thread for auto template parameters=
?</div></div></blockquote><div><br></div><div>No, it came up during discuss=
ion of N3601 at the Bristol WG21 meeting, but I don&#39;t believe there&#39=
;s any paper on it. (And at Bristol, EWG was pretty evenly divided between =
wanting N3601&#39;s syntax and wanting &#39;auto&#39;.)</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Den fred=
agen den 10:e januari 2014 kl. 16:35:15 UTC+1 skrev Alex B:</div></div><div=
 dir=3D"ltr">
<div><blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>On Friday, January 10, 2014 5:=
01:31 AM UTC-5, Bengt Gustafsson wrote:</div><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>=A0</div><div>=A0 =A0template&lt;...&gt; struct HeadI=
nfo;</div><div>=A0 =A0template&lt;typename T, ...&gt; struct HeadInfo&lt;T,=
 ...&gt; {</div><div>=A0 =A0 =A0 =A0static const bool is_type =3D true;</di=
v><div>=A0 =A0 =A0 =A0typedef T type;</div>
<div>=A0 =A0};</div><div>=A0 =A0template&lt;auto V, ...&gt; struct HeadInfo=
&lt;V, ...&gt; {</div><div>=A0 =A0 =A0 =A0static const bool is_type =3D fal=
se;</div><div>=A0 =A0 =A0 =A0typedef decltype(V) type;</div><div>=A0 =A0 =
=A0 =A0static const auto value =3D V;</div>
<div>=A0 =A0};</div><div>=A0</div></div></blockquote><div>=A0</div><div>Tha=
t syntax without ? would still require being able to name the generic pack.=
 Your example should be:</div><div>=A0</div><blockquote style=3D"margin-rig=
ht:0px" dir=3D"ltr">
<div><font face=3D"courier new,monospace">template&lt;typename T, ...<stron=
g><font color=3D"#ff0000">Tail</font></strong>&gt; struct HeadInfo&lt;T, <s=
trong><font color=3D"#ff0000">Tail</font></strong>...&gt; {</font></div><di=
v>
<font face=3D"courier new,monospace">       static const bool is_type =3D t=
rue;</font></div><div><font face=3D"courier new,monospace">       typedef T=
 type;</font></div><div><font face=3D"courier new,monospace">   };</font></=
div>
</blockquote><div>=A0</div><div>=A0</div><div>Giving a name would be requir=
ed to disambiguate cases where there is more than one generic pack:</div><d=
iv>=A0</div><blockquote style=3D"margin-right:0px" dir=3D"ltr"><div><font f=
ace=3D"courier new,monospace">template &lt;...&gt; struct A {};</font></div=
>
<div><font face=3D"courier new,monospace"></font>=A0</div><div><font face=
=3D"courier new,monospace">template &lt;class T, class U&gt;</font></div><d=
iv><font face=3D"courier new,monospace">struct B;</font></div><div><font fa=
ce=3D"courier new,monospace"></font>=A0</div>
<div><font face=3D"courier new,monospace">template &lt;...ElemsT, ...ElemsU=
&gt;</font></div><div><font face=3D"courier new,monospace">struct B&lt;A&lt=
;ElemsT...&gt;, A&lt;ElemsU...&gt;&gt;</font></div><div><font face=3D"couri=
er new,monospace">{</font></div>
<div><font face=3D"courier new,monospace">};</font></div></blockquote><div>=
=A0</div><div>As for actual use cases (with or without ?),=A0there is more =
than=A0metaprogramming refactoring sugar.=A0I can see at least one case=A0t=
hat it would allow to fix which is boost recursive variants:</div>
<div><a href=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_re=
cursive_variant.html" target=3D"_blank"><u><font color=3D"#0066cc">http://w=
ww.boost.org/doc/libs/<u></u>1_55_0/doc/html/boost/make_<u></u>recursive_va=
riant.html</font></u></a></div>
<div>Unless I&#39;m wrong, recursive variants currently cannot contain a te=
mplate type with non-type parameters, which is a bit annoying.=A0This featu=
re would make it possible.</div></div></blockquote></div></div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--bcaec5485ad06dfd2e04efa7211e--

.