------=_Part_3383_561506132.1420502139218
Content-Type: multipart/alternative;
 boundary="----=_Part_3384_1190415606.1420502139218"

------=_Part_3384_1190415606.1420502139218
Content-Type: text/plain; charset=UTF-8

The idea is pretty simple; given
*template* <*auto* V> *struct* v { *static constexpr* *auto* value = V; };
each of the following is valid:
*auto* v1 = v<5>::value;    // *decltype*(v1) is *int*
*auto* v2 = v<'a'>::value;  // *decltype*(v2) is *char*

Currently, if we want to accept a constant value as a template parameter,
its type must be specified:
*template* <*typename* T, T V> *struct* v { ... };

Using auto would allow the type of the constant to be deduced at the point
of instantiation rather than explicitly specified.

--

---
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_3384_1190415606.1420502139218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The idea is pretty simple; given<br><div style=3D"margin-l=
eft: 40px;"><font face=3D"courier new,monospace"><b>template</b> &lt;<b>aut=
o</b> V&gt; <b>struct</b> v { <b>static constexpr</b> <b>auto</b> value =3D=
 V; };</font><br></div>each of the following is valid:<br><div style=3D"mar=
gin-left: 40px;"><span style=3D"font-family: courier new,monospace;"><b>aut=
o</b> v1 =3D v&lt;5&gt;::value;&nbsp;&nbsp;&nbsp; // <b>decltype</b>(v1) is=
 <b>int</b><br><b>auto</b> v2 =3D v&lt;'a'&gt;::value;&nbsp; // <b>decltype=
</b>(v2) is <b>char</b><br></span></div><br>Currently, if we want to accept=
 a constant value as a template parameter, its type must be specified:<br><=
div style=3D"margin-left: 40px;"><span style=3D"font-family: courier new,mo=
nospace;"><b>template</b> &lt;<b>typename</b> T, T V&gt; <b>struct</b> v { =
.... };</span><br></div><br>Using auto would allow the type of the constant =
to be deduced at the point of instantiation rather than explicitly specifie=
d.<br><span style=3D"font-family: courier new,monospace;"></span></div>

<p></p>

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

------=_Part_3384_1190415606.1420502139218--
------=_Part_3383_561506132.1420502139218--

.

------=_Part_13319_2023473972.1420513517756
Content-Type: multipart/alternative;
 boundary="----=_Part_13320_1379000398.1420513517762"

------=_Part_13320_1379000398.1420513517762
Content-Type: text/plain; charset=UTF-8

With your idea, would it be valid to define `std::integer_sequence` as
    template<auto...I> struct integer_sequest {};

In other words, would `auto...I` refer to a variable number of auto-types
integers, or a variable number of integers, typed by auto?

On Monday, January 5, 2015 6:55:39 PM UTC-5, bek...@gmail.com wrote:
>
> The idea is pretty simple; given
> *template* <*auto* V> *struct* v { *static constexpr* *auto* value = V; };
> each of the following is valid:
> *auto* v1 = v<5>::value;    // *decltype*(v1) is *int*
> *auto* v2 = v<'a'>::value;  // *decltype*(v2) is *char*
>
> Currently, if we want to accept a constant value as a template parameter,
> its type must be specified:
> *template* <*typename* T, T V> *struct* v { ... };
>
> Using auto would allow the type of the constant to be deduced at the point
> of instantiation rather than explicitly specified.
>

--

---
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_13320_1379000398.1420513517762
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">With your idea, would it be valid to define `std::integer_=
sequence` as&nbsp;<div>&nbsp; &nbsp; template&lt;auto...I&gt; struct intege=
r_sequest {};</div><div><br></div><div>In other words, would `auto...I` ref=
er to a variable number of auto-types integers, or a variable number of int=
egers, typed by auto?</div><div><br>On Monday, January 5, 2015 6:55:39 PM U=
TC-5, bek...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">The idea is pretty simple; given<br><div style=3D"margin-le=
ft:40px"><font face=3D"courier new,monospace"><b>template</b> &lt;<b>auto</=
b> V&gt; <b>struct</b> v { <b>static constexpr</b> <b>auto</b> value =3D V;=
 };</font><br></div>each of the following is valid:<br><div style=3D"margin=
-left:40px"><span style=3D"font-family:courier new,monospace"><b>auto</b> v=
1 =3D v&lt;5&gt;::value;&nbsp;&nbsp;&nbsp; // <b>decltype</b>(v1) is <b>int=
</b><br><b>auto</b> v2 =3D v&lt;'a'&gt;::value;&nbsp; // <b>decltype</b>(v2=
) is <b>char</b><br></span></div><br>Currently, if we want to accept a cons=
tant value as a template parameter, its type must be specified:<br><div sty=
le=3D"margin-left:40px"><span style=3D"font-family:courier new,monospace"><=
b>template</b> &lt;<b>typename</b> T, T V&gt; <b>struct</b> v { ... };</spa=
n><br></div><br>Using auto would allow the type of the constant to be deduc=
ed at the point of instantiation rather than explicitly specified.<br><span=
 style=3D"font-family:courier new,monospace"></span></div></blockquote></di=
v></div>

<p></p>

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

------=_Part_13320_1379000398.1420513517762--
------=_Part_13319_2023473972.1420513517756--

.

------=_Part_596_1621546626.1420514552513
Content-Type: multipart/alternative;
 boundary="----=_Part_597_1766662752.1420514552514"

------=_Part_597_1766662752.1420514552514
Content-Type: text/plain; charset=UTF-8

My preference would be for template <auto... I> to independently deduce the
type of each argument.  This allows for lists of heterogeneous values, as
can already be done with types:
*template* <*typename*... Ts> *struct* type_list { };
*template* <*auto*... Vs> *struct* value_list { };
If you want to enforce a single type, you can already do that:
*template* <*typename* T, T... Vs> *struct* typed_value_list { };

On Monday, January 5, 2015 7:05:17 PM UTC-8, Scott Prager wrote:
>
> With your idea, would it be valid to define `std::integer_sequence` as
>     template<auto...I> struct integer_sequest {};
>
> In other words, would `auto...I` refer to a variable number of auto-types
> integers, or a variable number of integers, typed by auto?
>
> On Monday, January 5, 2015 6:55:39 PM UTC-5, bek...@gmail.com wrote:
>>
>> The idea is pretty simple; given
>> *template* <*auto* V> *struct* v { *static constexpr* *auto* value = V;
>> };
>> each of the following is valid:
>> *auto* v1 = v<5>::value;    // *decltype*(v1) is *int*
>> *auto* v2 = v<'a'>::value;  // *decltype*(v2) is *char*
>>
>> Currently, if we want to accept a constant value as a template parameter,
>> its type must be specified:
>> *template* <*typename* T, T V> *struct* v { ... };
>>
>> Using auto would allow the type of the constant to be deduced at the
>> point of instantiation rather than explicitly specified.
>>
>

--

---
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_597_1766662752.1420514552514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My preference would be for template &lt;auto... I&gt; to i=
ndependently deduce the type of each argument.&nbsp; This allows for lists =
of heterogeneous values, as can already be done with types:<br><div style=
=3D"margin-left: 40px;"><span style=3D"font-family: courier new,monospace;"=
><b>template</b> &lt;<b>typename</b>... Ts&gt; <b>struct</b> type_list { };=
<br><b>template</b> &lt;<b>auto</b>... Vs&gt; <b>struct</b> value_list { };=
</span><br></div>If you want to enforce a single type, you can already do t=
hat:<br><div style=3D"margin-left: 40px;"><span style=3D"font-family: couri=
er new,monospace;"><b>template</b> &lt;<b>typename</b> T, T... Vs&gt; <b>st=
ruct</b> typed_value_list { };</span><br></div><br>On Monday, January 5, 20=
15 7:05:17 PM UTC-8, Scott Prager wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">With your idea, would it be valid to define `std=
::integer_sequence` as&nbsp;<div>&nbsp; &nbsp; template&lt;auto...I&gt; str=
uct integer_sequest {};</div><div><br></div><div>In other words, would `aut=
o...I` refer to a variable number of auto-types integers, or a variable num=
ber of integers, typed by auto?</div><div><br>On Monday, January 5, 2015 6:=
55:39 PM UTC-5, <a>bek...@gmail.com</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">The idea is pretty simple; given<br><div style=
=3D"margin-left:40px"><font face=3D"courier new,monospace"><b>template</b> =
&lt;<b>auto</b> V&gt; <b>struct</b> v { <b>static constexpr</b> <b>auto</b>=
 value =3D V; };</font><br></div>each of the following is valid:<br><div st=
yle=3D"margin-left:40px"><span style=3D"font-family:courier new,monospace">=
<b>auto</b> v1 =3D v&lt;5&gt;::value;&nbsp;&nbsp;&nbsp; // <b>decltype</b>(=
v1) is <b>int</b><br><b>auto</b> v2 =3D v&lt;'a'&gt;::value;&nbsp; // <b>de=
cltype</b>(v2) is <b>char</b><br></span></div><br>Currently, if we want to =
accept a constant value as a template parameter, its type must be specified=
:<br><div style=3D"margin-left:40px"><span style=3D"font-family:courier new=
,monospace"><b>template</b> &lt;<b>typename</b> T, T V&gt; <b>struct</b> v =
{ ... };</span><br></div><br>Using auto would allow the type of the constan=
t to be deduced at the point of instantiation rather than explicitly specif=
ied.<br><span style=3D"font-family:courier new,monospace"></span></div></bl=
ockquote></div></div></blockquote></div>

<p></p>

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

------=_Part_597_1766662752.1420514552514--
------=_Part_596_1621546626.1420514552513--

.

bekenn@gmail.com writes:

| The idea is pretty simple; given
| template <auto V> struct v { static constexpr auto value = V; };

+1.

It has been suggested many many times over the last decade -- and lately
within the development of the "concept lite" effort.  We just need a
actionable proposal to vote on :-)

-- Gaby

--

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

.

+100.  Also for template functions.  See the thread I started, for example.

On 1/7/15, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> bekenn@gmail.com writes:
>
> | The idea is pretty simple; given
> | template <auto V> struct v { static constexpr auto value = V; };
>
> +1.
>
> It has been suggested many many times over the last decade -- and lately
> within the development of the "concept lite" effort.  We just need a
> actionable proposal to vote on :-)
>
> -- Gaby
>
> --
>
> ---
> 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/.

.

------=_Part_134_877651560.1420696443399
Content-Type: multipart/alternative;
 boundary="----=_Part_135_1772081324.1420696443399"

------=_Part_135_1772081324.1420696443399
Content-Type: text/plain; charset=UTF-8

I guess I'd better figure out how to write one, then....

On Wednesday, January 7, 2015 6:34:02 AM UTC-8, Gabriel Dos Reis wrote:
>
> bek...@gmail.com <javascript:> writes:
>
> | The idea is pretty simple; given
> | template <auto V> struct v { static constexpr auto value = V; };
>
> +1.
>
> It has been suggested many many times over the last decade -- and lately
> within the development of the "concept lite" effort.  We just need a
> actionable proposal to vote on :-)
>
> -- Gaby
>

--

---
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_135_1772081324.1420696443399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I guess I'd better figure out how to write one, then....<b=
r><br>On Wednesday, January 7, 2015 6:34:02 AM UTC-8, Gabriel Dos Reis wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"TA1mwvlJW6oJ" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">bek...@gmail.com</a> writes:
<br>
<br>| The idea is pretty simple; given
<br>| template &lt;auto V&gt; struct v { static constexpr auto value =3D V;=
 };
<br>
<br>+1. &nbsp;
<br>
<br>It has been suggested many many times over the last decade -- and latel=
y
<br>within the development of the "concept lite" effort. &nbsp;We just need=
 a
<br>actionable proposal to vote on :-)
<br>
<br>-- Gaby
<br></blockquote></div>

<p></p>

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

------=_Part_135_1772081324.1420696443399--
------=_Part_134_877651560.1420696443399--

.

------=_Part_1419_1161643624.1420709128726
Content-Type: multipart/alternative;
 boundary="----=_Part_1420_970553691.1420709128726"

------=_Part_1420_970553691.1420709128726
Content-Type: text/plain; charset=UTF-8



On Thursday, January 8, 2015 6:54:03 PM UTC+13, bek...@gmail.com wrote:
>
> I guess I'd better figure out how to write one, then....
>
>
>> This might be useful to your proposal if you haven't seen it.
http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/
It sounds like your proposal could make this library a built in feature of
the language or make that library a whole lot less code?:
I'm sure Eric has his hands pretty full with his core Range proposal but he
might be a good person to help you figure out your proposal or the process.
Anyway, congratulations for getting "the nod" for a proposal!

--

---
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_1420_970553691.1420709128726
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, January 8, 2015 6:54:03 PM UTC+13, be=
k...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I guess =
I'd better figure out how to write one, then....<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><br></blockquote></div></blockquote><div><div>This might be use=
ful to your proposal&nbsp;if you haven't seen it.</div><a href=3D"http://er=
icniebler.com/2014/11/13/tiny-metaprogramming-library/">http://ericniebler.=
com/2014/11/13/tiny-metaprogramming-library/</a></div><div><div>It sounds l=
ike your proposal&nbsp;could make this library a built in feature of the la=
nguage or make that library a whole lot less code?:</div>I'm sure&nbsp;Eric=
 has his hands pretty full with his core Range proposal but he might be a g=
ood person to help you figure out&nbsp;your proposal or the process.</div><=
div>Anyway, congratulations for getting "the nod" for a proposal!</div></di=
v>

<p></p>

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

------=_Part_1420_970553691.1420709128726--
------=_Part_1419_1161643624.1420709128726--

.

------=_Part_16_822473910.1420711486326
Content-Type: multipart/alternative;
 boundary="----=_Part_17_2114253278.1420711486326"

------=_Part_17_2114253278.1420711486326
Content-Type: text/plain; charset=UTF-8

Thanks, I'll definitely reach out to him.  (Incidentally, his ranges paper
actually mentions my range library, available here
<https://github.com/Bekenn/range>.)

I've completed an initial draft of a proposal document, which can be found
here <https://github.com/Bekenn/isocpp/blob/master/template-auto.html>.
The code samples may or may not work; I haven't had a chance to try them
yet, I simply typed them stream-of-consciousness style.  Any feedback from
the list would be appreciated.

On Thursday, January 8, 2015 1:25:28 AM UTC-8, gmis...@gmail.com wrote:
>
>
>
> On Thursday, January 8, 2015 6:54:03 PM UTC+13, bek...@gmail.com wrote:
>>
>> I guess I'd better figure out how to write one, then....
>>
>>
>>> This might be useful to your proposal if you haven't seen it.
> http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/
> It sounds like your proposal could make this library a built in feature of
> the language or make that library a whole lot less code?:
> I'm sure Eric has his hands pretty full with his core Range proposal but
> he might be a good person to help you figure out your proposal or the
> process.
> Anyway, congratulations for getting "the nod" for a proposal!
>

--

---
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_17_2114253278.1420711486326
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks, I'll definitely reach out to him.&nbsp; (Incidenta=
lly, his ranges paper actually mentions my range library, available <a href=
=3D"https://github.com/Bekenn/range">here</a>.)<br><br>I've completed an in=
itial draft of a proposal document, which can be found <a href=3D"https://g=
ithub.com/Bekenn/isocpp/blob/master/template-auto.html">here</a>.&nbsp; The=
 code samples may or may not work; I haven't had a chance to try them yet, =
I simply typed them stream-of-consciousness style.&nbsp; Any feedback from =
the list would be appreciated.<br><br>On Thursday, January 8, 2015 1:25:28 =
AM UTC-8, gmis...@gmail.com wrote:<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"><br><br>On Thursday, January 8, 2015 6:54:03 PM UTC+=
13, <a>bek...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 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">I gue=
ss I'd better figure out how to write one, then....<br><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
><br></blockquote></div></blockquote><div><div>This might be useful to your=
 proposal&nbsp;if you haven't seen it.</div><a href=3D"http://ericniebler.c=
om/2014/11/13/tiny-metaprogramming-library/" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fericniebler.com=
%2F2014%2F11%2F13%2Ftiny-metaprogramming-library%2F\46sa\75D\46sntz\0751\46=
usg\75AFQjCNEO_nuWuPUyyNwZnIb5d5nYtemCLQ';return true;" onclick=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fericniebler.com%2F2014%2F11=
%2F13%2Ftiny-metaprogramming-library%2F\46sa\75D\46sntz\0751\46usg\75AFQjCN=
EO_nuWuPUyyNwZnIb5d5nYtemCLQ';return true;">http://ericniebler.com/2014/<wb=
r>11/13/tiny-metaprogramming-<wbr>library/</a></div><div><div>It sounds lik=
e your proposal&nbsp;could make this library a built in feature of the lang=
uage or make that library a whole lot less code?:</div>I'm sure&nbsp;Eric h=
as his hands pretty full with his core Range proposal but he might be a goo=
d person to help you figure out&nbsp;your proposal or the process.</div><di=
v>Anyway, congratulations for getting "the nod" for a proposal!</div></div>=
</blockquote></div>

<p></p>

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

------=_Part_17_2114253278.1420711486326--
------=_Part_16_822473910.1420711486326--

.

------=_Part_338_1013582253.1420786896066
Content-Type: multipart/alternative;
 boundary="----=_Part_339_1436638167.1420786896066"

------=_Part_339_1436638167.1420786896066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, January 8, 2015 at 2:04:46 AM UTC-8, bek...@gmail.com wrote:
>
> Thanks, I'll definitely reach out to him.  (Incidentally, his ranges pape=
r=20
> actually mentions my range library, available here=20
> <https://github.com/Bekenn/range>.)
>
> I've completed an initial draft of a proposal document, which can be foun=
d=20
> here <https://github.com/Bekenn/isocpp/blob/master/template-auto.html>. =
=20
> The code samples may or may not work; I haven't had a chance to try them=
=20
> yet, I simply typed them stream-of-consciousness style.  Any feedback fro=
m=20
> the list would be appreciated.
>

Protip: If you create a "gh-pages" branch in that repository, and put your=
=20
document into that branch, Github will automagically create a page=20
https://Bekenn.github.io/isocpp/template-auto.html which will allow people=
=20
to see the document as it is meant to be seen.
Of course, I may be missing an even pro-er tip that would let you link=20
directly to your page without creating a gh-pages branch... but I imagine=
=20
Github prevents that for reasons related to XSS attacks.

    // can't specify string literals as template arguments, so provide a ch=
aracter array instead
    *static* *constexpr* *char* cbname[] =3D "my_callback";=20

    library::register_callback(logger<my_callback, cbname>);=20

FWIW, it took me a long time to get this code "working" with Clang 3.5,=20
because the expression register_callback(...) must appear in a local scope,=
=20
but the static constexpr char cbname[] must appear at file scope, at least=
=20
with my compiler =E2=80=94 if it's in a local scope, you get a tersely cryp=
tic=20
error message from Clang. I recommend providing a completely=20
cut-and-pasteable example, which in this case is as simple as adding auto=
=20
foo =3D in front of the register_callback line to turn it into something th=
at=20
can legally appear at file scope.

The "Impact on the Standard" section seems a bit too one-sided. ;)  Can you=
=20
consider and address any concerns that might come up re: opportunity costs=
=20
of standardizing *this* meaning for template<auto> as opposed to any other=
=20
meaning that might come along later?  Particularly, I wonder whether=20
there's any chance of getting a syntax for "template on a thing and I don't=
=20
care what kind of thing it is", such that one could write

    template<anything x> size_t SizeOf =3D sizeof(x);
    auto one =3D SizeOf<char>;  // 'anything' is here a synonym for 'typena=
me'
    auto four =3D SizeOf<42>;  // 'anything' is here a synonym for 'int'

    template<anything f, anything... x> using Apply =3D f<x...>;
    using beta =3D Apply<std::array, int, 3>;  // the first 'anything' is=
=20
here a synonym for 'template<typename, size_t> class'

Would this proposal, if adopted, block any possibility of using auto for=20
the keyword I'm calling anything above?
On the other hand, modern C++ seems to gravitate toward using as the=20
keyword for "anything, don't know, don't care" (at least it can be used in=
=20
contexts requiring either typenames or namespaces at the moment). Discuss.=
=20
:)

=E2=80=93Arthur

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

------=_Part_339_1436638167.1420786896066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, January 8, 2015 at 2:04:46 AM UTC-8, bek...@g=
mail.com wrote:<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=
">Thanks, I'll definitely reach out to him.&nbsp; (Incidentally, his ranges=
 paper actually mentions my range library, available <a href=3D"https://git=
hub.com/Bekenn/range" target=3D"_blank" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FBekenn%2Frange\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEvpjAMZiHsJ6LcfykBCrBo9jJnog';return true;" oncli=
ck=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%=
2FBekenn%2Frange\46sa\75D\46sntz\0751\46usg\75AFQjCNEvpjAMZiHsJ6LcfykBCrBo9=
jJnog';return true;">here</a>.)<br><br>I've completed an initial draft of a=
 proposal document, which can be found <a href=3D"https://github.com/Bekenn=
/isocpp/blob/master/template-auto.html" target=3D"_blank" onmousedown=3D"th=
is.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FBekenn=
%2Fisocpp%2Fblob%2Fmaster%2Ftemplate-auto.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNF9lwi-wmv70idsR7kBhCGrEDPAAg';return true;" onclick=3D"this.href=3D'=
https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FBekenn%2Fisocpp%2=
Fblob%2Fmaster%2Ftemplate-auto.html\46sa\75D\46sntz\0751\46usg\75AFQjCNF9lw=
i-wmv70idsR7kBhCGrEDPAAg';return true;">here</a>.&nbsp; The code samples ma=
y or may not work; I haven't had a chance to try them yet, I simply typed t=
hem stream-of-consciousness style.&nbsp; Any feedback from the list would b=
e appreciated.<br></div></blockquote><div><br></div><div>Protip: If you cre=
ate a "gh-pages" branch in that repository, and put your document into that=
 branch, Github will automagically create a page https://Bekenn.github.io/i=
socpp/template-auto.html which will allow people to see the document as it =
is meant to be seen.</div><div>Of course, I may be missing an even pro-er t=
ip that would let you link directly to your page without creating a gh-page=
s branch... but I imagine Github prevents that for reasons related to XSS a=
ttacks.</div><div><br></div><pre style=3D"color: rgb(0, 0, 0);"><font face=
=3D"courier new, monospace">    // can't specify string literals as templat=
e arguments, so provide a character array instead
    <b>static</b> <b>constexpr</b> <b>char</b> cbname[] =3D "my_callback";&=
nbsp;</font></pre><div><font face=3D"courier new, monospace"><span style=3D=
"color: rgb(0, 0, 0);">&nbsp; &nbsp; library::register_callback(logger&lt;m=
y_callback, cbname&gt;);</span>&nbsp;</font></div><div><br></div><div>FWIW,=
 it took me a long time to get this code "working" with Clang 3.5, because =
the expression <font face=3D"courier new, monospace">register_callback(...)=
</font> must appear in a local scope, but the <font face=3D"courier new, mo=
nospace">static constexpr char cbname[]</font> must appear at file scope, a=
t least with my compiler =E2=80=94 if it's in a local scope, you get a ters=
ely cryptic error message from Clang. I recommend providing a completely cu=
t-and-pasteable example, which in this case is as simple as adding <font fa=
ce=3D"courier new, monospace">auto foo =3D</font> in front of the <font fac=
e=3D"courier new, monospace">register_callback</font> line to turn it into =
something that can legally appear at file scope.</div><div><br></div><div>T=
he "Impact on the Standard" section seems a bit too one-sided. ;) &nbsp;Can=
 you consider and address any concerns that might come up re: opportunity c=
osts of standardizing *this* meaning for template&lt;auto&gt; as opposed to=
 any other meaning that might come along later? &nbsp;Particularly, I wonde=
r whether there's any chance of getting a syntax for "template on a thing a=
nd I don't care what kind of thing it is", such that one could write</div><=
div><br></div><div>&nbsp; &nbsp; template&lt;anything x&gt; size_t SizeOf =
=3D sizeof(x);</div><div>&nbsp; &nbsp; auto one =3D SizeOf&lt;char&gt;; &nb=
sp;// 'anything' is here a synonym for 'typename'</div><div>&nbsp; &nbsp; a=
uto four =3D SizeOf&lt;42&gt;; &nbsp;// 'anything' is here a synonym for 'i=
nt'</div><div><br></div><div>&nbsp; &nbsp; template&lt;anything f, anything=
.... x&gt; using Apply =3D f&lt;x...&gt;;</div><div>&nbsp; &nbsp; using beta=
 =3D Apply&lt;std::array, int, 3&gt;; &nbsp;// the first 'anything' is here=
 a synonym for 'template&lt;typename, size_t&gt; class'<br></div><div><br><=
/div><div>Would this proposal, if adopted, block any possibility of using <=
font face=3D"courier new, monospace">auto</font> for the keyword I'm callin=
g&nbsp;<font face=3D"courier new, monospace">anything</font>&nbsp;above?</d=
iv><div>On the other hand, modern C++ seems to gravitate toward <font face=
=3D"courier new, monospace">using</font> as the keyword for "anything, don'=
t know, don't care" (at least it can be used in contexts requiring either t=
ypenames or namespaces at the moment). Discuss. :)</div><div><br></div><div=
>=E2=80=93Arthur</div></div>

<p></p>

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

------=_Part_339_1436638167.1420786896066--
------=_Part_338_1013582253.1420786896066--

.

------=_Part_478_367789843.1420794642945
Content-Type: multipart/alternative;
 boundary="----=_Part_479_985955235.1420794642945"

------=_Part_479_985955235.1420794642945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the tip!  The readable version of the proposal is now available=
=20
here <http://bekenn.github.io/isocpp/template-auto.html>.

I'm surprised that the character array has to be at file scope; I would=20
have expected that to work anywhere.

I'll see what I can do about the "Impact on the Standard" section; I hadn't=
=20
considered that anyone might want to use auto for that purpose. Although I=
=20
certainly agree that a keyword meaning "anything at all" would be useful, I=
=20
think auto is very clearly associated with values.  I'll think on that, and=
=20
maybe come up with an alternative for "anything at all." (Perhaps no=20
keyword?  Just an identifier?)

Thanks for the feedback!

On Thursday, January 8, 2015 at 11:01:36 PM UTC-8, Arthur O'Dwyer wrote:
>
> On Thursday, January 8, 2015 at 2:04:46 AM UTC-8, bek...@gmail.com wrote:
>>
>> Thanks, I'll definitely reach out to him.  (Incidentally, his ranges=20
>> paper actually mentions my range library, available here=20
>> <https://github.com/Bekenn/range>.)
>>
>> I've completed an initial draft of a proposal document, which can be=20
>> found here=20
>> <https://github.com/Bekenn/isocpp/blob/master/template-auto.html>.  The=
=20
>> code samples may or may not work; I haven't had a chance to try them yet=
, I=20
>> simply typed them stream-of-consciousness style.  Any feedback from the=
=20
>> list would be appreciated.
>>
>
> Protip: If you create a "gh-pages" branch in that repository, and put you=
r=20
> document into that branch, Github will automagically create a page=20
> https://Bekenn.github.io/isocpp/template-auto.html which will allow=20
> people to see the document as it is meant to be seen.
> Of course, I may be missing an even pro-er tip that would let you link=20
> directly to your page without creating a gh-pages branch... but I imagine=
=20
> Github prevents that for reasons related to XSS attacks.
>
>     // can't specify string literals as template arguments, so provide a =
character array instead
>     *static* *constexpr* *char* cbname[] =3D "my_callback";=20
>
>     library::register_callback(logger<my_callback, cbname>);=20
>
> FWIW, it took me a long time to get this code "working" with Clang 3.5,=
=20
> because the expression register_callback(...) must appear in a local=20
> scope, but the static constexpr char cbname[] must appear at file scope,=
=20
> at least with my compiler =E2=80=94 if it's in a local scope, you get a t=
ersely=20
> cryptic error message from Clang. I recommend providing a completely=20
> cut-and-pasteable example, which in this case is as simple as adding auto=
=20
> foo =3D in front of the register_callback line to turn it into something=
=20
> that can legally appear at file scope.
>
> The "Impact on the Standard" section seems a bit too one-sided. ;)  Can=
=20
> you consider and address any concerns that might come up re: opportunity=
=20
> costs of standardizing *this* meaning for template<auto> as opposed to an=
y=20
> other meaning that might come along later?  Particularly, I wonder whethe=
r=20
> there's any chance of getting a syntax for "template on a thing and I don=
't=20
> care what kind of thing it is", such that one could write
>
>     template<anything x> size_t SizeOf =3D sizeof(x);
>     auto one =3D SizeOf<char>;  // 'anything' is here a synonym for=20
> 'typename'
>     auto four =3D SizeOf<42>;  // 'anything' is here a synonym for 'int'
>
>     template<anything f, anything... x> using Apply =3D f<x...>;
>     using beta =3D Apply<std::array, int, 3>;  // the first 'anything' is=
=20
> here a synonym for 'template<typename, size_t> class'
>
> Would this proposal, if adopted, block any possibility of using auto for=
=20
> the keyword I'm calling anything above?
> On the other hand, modern C++ seems to gravitate toward using as the=20
> keyword for "anything, don't know, don't care" (at least it can be used i=
n=20
> contexts requiring either typenames or namespaces at the moment). Discuss=
..=20
> :)
>
> =E2=80=93Arthur
>

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

------=_Part_479_985955235.1420794642945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the tip!&nbsp; The readable version of the prop=
osal is now available <a href=3D"http://bekenn.github.io/isocpp/template-au=
to.html">here</a>.<br><br>I'm surprised that the character array has to be =
at file scope; I would have expected that to work anywhere.<br><br>I'll see=
 what I can do about the "Impact on the Standard" section; I hadn't conside=
red that anyone might want to use <span style=3D"font-family: courier new,m=
onospace;">auto</span> for that purpose. Although I certainly agree that a =
keyword meaning "anything at all" would be useful, I think <span style=3D"f=
ont-family: courier new,monospace;">auto</span> is very clearly associated =
with values.&nbsp; I'll think on that, and maybe come up with an alternativ=
e for "anything at all." (Perhaps no keyword?&nbsp; Just an identifier?)<br=
><br>Thanks for the feedback!<br><br>On Thursday, January 8, 2015 at 11:01:=
36 PM UTC-8, Arthur O'Dwyer wrote:<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">On Thursday, January 8, 2015 at 2:04:46 AM UTC-8, <a=
>bek...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Thanks, I'll definitely reach out to him.&nbsp; (Incidentally, hi=
s ranges paper actually mentions my range library, available <a href=3D"htt=
ps://github.com/Bekenn/range" target=3D"_blank" onmousedown=3D"this.href=3D=
'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FBekenn%2Frange\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNEvpjAMZiHsJ6LcfykBCrBo9jJnog';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgit=
hub.com%2FBekenn%2Frange\46sa\75D\46sntz\0751\46usg\75AFQjCNEvpjAMZiHsJ6Lcf=
ykBCrBo9jJnog';return true;">here</a>.)<br><br>I've completed an initial dr=
aft of a proposal document, which can be found <a href=3D"https://github.co=
m/Bekenn/isocpp/blob/master/template-auto.html" target=3D"_blank" onmousedo=
wn=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%=
2FBekenn%2Fisocpp%2Fblob%2Fmaster%2Ftemplate-auto.html\46sa\75D\46sntz\0751=
\46usg\75AFQjCNF9lwi-wmv70idsR7kBhCGrEDPAAg';return true;" onclick=3D"this.=
href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FBekenn%2F=
isocpp%2Fblob%2Fmaster%2Ftemplate-auto.html\46sa\75D\46sntz\0751\46usg\75AF=
QjCNF9lwi-wmv70idsR7kBhCGrEDPAAg';return true;">here</a>.&nbsp; The code sa=
mples may or may not work; I haven't had a chance to try them yet, I simply=
 typed them stream-of-consciousness style.&nbsp; Any feedback from the list=
 would be appreciated.<br></div></blockquote><div><br></div><div>Protip: If=
 you create a "gh-pages" branch in that repository, and put your document i=
nto that branch, Github will automagically create a page <a href=3D"https:/=
/Bekenn.github.io/isocpp/template-auto.html" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2FBekenn.github=
..io%2Fisocpp%2Ftemplate-auto.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHus6rr=
Ns1mhKoZ3XailXEJDir7uQ';return true;" onclick=3D"this.href=3D'https://www.g=
oogle.com/url?q\75https%3A%2F%2FBekenn.github.io%2Fisocpp%2Ftemplate-auto.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNHus6rrNs1mhKoZ3XailXEJDir7uQ';return=
 true;">https://Bekenn.github.io/<wbr>isocpp/template-auto.html</a> which w=
ill allow people to see the document as it is meant to be seen.</div><div>O=
f course, I may be missing an even pro-er tip that would let you link direc=
tly to your page without creating a gh-pages branch... but I imagine Github=
 prevents that for reasons related to XSS attacks.</div><div><br></div><pre=
 style=3D"color:rgb(0,0,0)"><font face=3D"courier new, monospace">    // ca=
n't specify string literals as template arguments, so provide a character a=
rray instead
    <b>static</b> <b>constexpr</b> <b>char</b> cbname[] =3D "my_callback";&=
nbsp;</font></pre><div><font face=3D"courier new, monospace"><span style=3D=
"color:rgb(0,0,0)">&nbsp; &nbsp; library::register_callback(<wbr>logger&lt;=
my_callback, cbname&gt;);</span>&nbsp;</font></div><div><br></div><div>FWIW=
, it took me a long time to get this code "working" with Clang 3.5, because=
 the expression <font face=3D"courier new, monospace">register_callback(...=
)</font> must appear in a local scope, but the <font face=3D"courier new, m=
onospace">static constexpr char cbname[]</font> must appear at file scope, =
at least with my compiler =E2=80=94 if it's in a local scope, you get a ter=
sely cryptic error message from Clang. I recommend providing a completely c=
ut-and-pasteable example, which in this case is as simple as adding <font f=
ace=3D"courier new, monospace">auto foo =3D</font> in front of the <font fa=
ce=3D"courier new, monospace">register_callback</font> line to turn it into=
 something that can legally appear at file scope.</div><div><br></div><div>=
The "Impact on the Standard" section seems a bit too one-sided. ;) &nbsp;Ca=
n you consider and address any concerns that might come up re: opportunity =
costs of standardizing *this* meaning for template&lt;auto&gt; as opposed t=
o any other meaning that might come along later? &nbsp;Particularly, I wond=
er whether there's any chance of getting a syntax for "template on a thing =
and I don't care what kind of thing it is", such that one could write</div>=
<div><br></div><div>&nbsp; &nbsp; template&lt;anything x&gt; size_t SizeOf =
=3D sizeof(x);</div><div>&nbsp; &nbsp; auto one =3D SizeOf&lt;char&gt;; &nb=
sp;// 'anything' is here a synonym for 'typename'</div><div>&nbsp; &nbsp; a=
uto four =3D SizeOf&lt;42&gt;; &nbsp;// 'anything' is here a synonym for 'i=
nt'</div><div><br></div><div>&nbsp; &nbsp; template&lt;anything f, anything=
.... x&gt; using Apply =3D f&lt;x...&gt;;</div><div>&nbsp; &nbsp; using beta=
 =3D Apply&lt;std::array, int, 3&gt;; &nbsp;// the first 'anything' is here=
 a synonym for 'template&lt;typename, size_t&gt; class'<br></div><div><br><=
/div><div>Would this proposal, if adopted, block any possibility of using <=
font face=3D"courier new, monospace">auto</font> for the keyword I'm callin=
g&nbsp;<font face=3D"courier new, monospace">anything</font>&nbsp;above?</d=
iv><div>On the other hand, modern C++ seems to gravitate toward <font face=
=3D"courier new, monospace">using</font> as the keyword for "anything, don'=
t know, don't care" (at least it can be used in contexts requiring either t=
ypenames or namespaces at the moment). Discuss. :)</div><div><br></div><div=
>=E2=80=93Arthur</div></div></blockquote></div>

<p></p>

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

------=_Part_479_985955235.1420794642945--
------=_Part_478_367789843.1420794642945--

.

--Apple-Mail=_E2DF8B88-9911-44A9-9D80-314748E30911
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


Il giorno 06/gen/2015, alle ore 04:22, bekenn@gmail.com ha scritto:

> My preference would be for template <auto... I> to independently deduce t=
he type of each argument.  This allows for lists of heterogeneous values, a=
s can already be done with types:
> template <typename... Ts> struct type_list { };
> template <auto... Vs> struct value_list { };
> If you want to enforce a single type, you can already do that:
> template <typename T, T... Vs> struct typed_value_list { };

Hi.

I think it would be annoyingly inconsistent with the way auto works for var=
iable initializers:

auto i =3D 0, j =3D 1; // i and j must deduce to the same type

The alternative you provide is not exactly the same in function templates, =
because
I can=E2=80=99t let the compiler deduce T from the other arguments:

template <typename T, T... Vs> void func() { };

func<4,5,6>(); // no way


Anyway, there=E2=80=99s something more than consistency. You say =E2=80=9Ca=
s can already be done with types=E2=80=9D.
This is not completely correct. At the type level, types have all the same =
kind (type of types).
Until Concepts Lite, at least.
Then we have non-type parameters which have distinct type, at type level. S=
o at type level
we have only a bunch of basic types-of-type available, without the ability =
to form more complex
types from these ones: bool, char, int ecc=E2=80=A6 together with typename =
and template template parameters.

So when you say =E2=80=9Ctypename=E2=80=9D you=E2=80=99re not allowing hete=
rogeneous values. The =E2=80=9Cvalues=E2=80=9D, which are the
types, have all the same kind.

That links also to the other proposal of the =E2=80=9Canything at all=E2=80=
=9D keyword. It seems to me that restricting
the use of auto in this context to only non-type parameters is a bit stretc=
hed. It=E2=80=99s as if the auto
keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=80=
=99:

auto i =3D 42; // Not allowed: you can use auto only for non-int values.

Can you immagine it?
From a type system point of view there=E2=80=99s no difference, we=E2=80=99=
re only lifting
the feature to type-level instead of data-level values.

So IMHO the feature should work consistently with the current way the auto =
keyword works for
values, and moreover it should work like te =E2=80=9Canything at all=E2=80=
=9D keyword that was proposed in
the other mail.

Bye,
Nicola

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

--Apple-Mail=_E2DF8B88-9911-44A9-9D80-314748E30911
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;" class=3D""><br class=
=3D""><div><div class=3D"">Il giorno 06/gen/2015, alle ore 04:22, <a href=
=3D"mailto:bekenn@gmail.com">bekenn@gmail.com</a> ha scritto:</div><br clas=
s=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr" =
class=3D"">My preference would be for template &lt;auto... I&gt; to indepen=
dently deduce the type of each argument.&nbsp; This allows for lists of het=
erogeneous values, as can already be done with types:<br class=3D""><div st=
yle=3D"margin-left: 40px;" class=3D""><span style=3D"font-family: courier n=
ew,monospace;" class=3D""><b class=3D"">template</b> &lt;<b class=3D"">type=
name</b>... Ts&gt; <b class=3D"">struct</b> type_list { };<br class=3D""><b=
 class=3D"">template</b> &lt;<b class=3D"">auto</b>... Vs&gt; <b class=3D""=
>struct</b> value_list { };</span><br class=3D""></div>If you want to enfor=
ce a single type, you can already do that:<br class=3D""><div style=3D"marg=
in-left: 40px;" class=3D""><span style=3D"font-family: courier new,monospac=
e;" class=3D""><b class=3D"">template</b> &lt;<b class=3D"">typename</b> T,=
 T... Vs&gt; <b class=3D"">struct</b> typed_value_list { };</span><br class=
=3D""></div></div></blockquote></div><br class=3D""><div class=3D"">Hi.</di=
v><div class=3D""><br class=3D""></div><div class=3D"">I think it would be =
annoyingly inconsistent with the way auto works for variable initializers:<=
/div><div class=3D""><br class=3D""></div><div class=3D"">auto i =3D 0, j =
=3D 1; // i and j must deduce to the same type</div><div class=3D""><br cla=
ss=3D""></div><div class=3D"">The alternative you provide is not exactly th=
e same in function templates, because</div><div class=3D"">I can=E2=80=99t =
let the compiler deduce T from the other arguments:</div><div class=3D""><b=
r class=3D""></div><div class=3D""><b class=3D"" style=3D"font-family: 'cou=
rier new', monospace;">template</b><span style=3D"font-family: 'courier new=
', monospace;">&nbsp;</span><span style=3D"font-family: 'courier new', mono=
space;">&lt;</span><b class=3D"" style=3D"font-family: 'courier new', monos=
pace;">typename</b><span style=3D"font-family: 'courier new', monospace;">&=
nbsp;</span><span style=3D"font-family: 'courier new', monospace;">T, T... =
Vs&gt;</span><span style=3D"font-family: 'courier new', monospace;">&nbsp;<=
/span><b class=3D"" style=3D"font-family: 'courier new', monospace;">void</=
b><span style=3D"font-family: 'courier new', monospace;">&nbsp;func() { };<=
/span><br><br>func&lt;4,5,6&gt;(); // no way</div><div class=3D""><br></div=
><div class=3D""><br></div><div class=3D"">Anyway, there=E2=80=99s somethin=
g more than consistency. You say =E2=80=9Cas can already be done with types=
=E2=80=9D.</div><div class=3D"">This is not completely correct. At the type=
 level, types have all the same kind (type of types).</div><div class=3D"">=
Until Concepts Lite, at least.</div><div class=3D"">Then we have non-type p=
arameters which have distinct type, at type level. So at type level</div><d=
iv class=3D"">we have only a bunch of basic types-of-type available, withou=
t the ability to form more complex</div><div class=3D"">types from these on=
es: bool, char, int ecc=E2=80=A6 together with typename and template templa=
te parameters.</div><div class=3D""><br></div><div class=3D"">So when you s=
ay =E2=80=9Ctypename=E2=80=9D you=E2=80=99re not allowing heterogeneous val=
ues. The =E2=80=9Cvalues=E2=80=9D, which are the</div><div class=3D"">types=
, have all the same kind.</div><div class=3D""><br></div><div class=3D"">Th=
at links also to the other proposal of the =E2=80=9Canything at all=E2=80=
=9D keyword. It seems to me that restricting</div><div class=3D"">the use o=
f auto in this context to only non-type parameters is a bit stretched. It=
=E2=80=99s as if the auto</div><div class=3D"">keyword in C++11 was allowed=
 to deduce any type except =E2=80=98int=E2=80=99:</div><div class=3D""><br>=
</div><div class=3D"">auto i =3D 42; // Not allowed: you can use auto only =
for non-int values.</div><div class=3D""><br></div><div class=3D"">Can you =
immagine it?</div><div class=3D"">From a type system point of view there=E2=
=80=99s no difference, we=E2=80=99re only lifting</div><div class=3D"">the =
feature to type-level instead of data-level values.</div><div class=3D""><b=
r></div><div class=3D"">So IMHO the feature should work consistently with t=
he current way the auto keyword works for</div><div class=3D"">values, and =
moreover it should work like te =E2=80=9Canything at all=E2=80=9D keyword t=
hat was proposed in</div><div class=3D"">the other mail.</div><div class=3D=
""><br></div><div class=3D"">Bye,</div><div class=3D"">Nicola</div><div cla=
ss=3D""><br></div></body></html>

<p></p>

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

--Apple-Mail=_E2DF8B88-9911-44A9-9D80-314748E30911--

.

------=_Part_566_404263360.1420799719612
Content-Type: multipart/alternative;
 boundary="----=_Part_567_1963516059.1420799719612"

------=_Part_567_1963516059.1420799719612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wrote:
>
>
> Hi.
>
> I think it would be annoyingly inconsistent with the way auto works for=
=20
> variable initializers:
>
> auto i =3D 0, j =3D 1; // i and j must deduce to the same type
>

I actually don't see an inconsistency here.  With variable initializers,=20
there's only one occurrence of the keyword auto, but in a parameter pack=20
declaration, there are conceptually as many occurrences as there are items=
=20
in the pack, such that the declaration template <auto... xs> expands to tem=
plate=20
<auto x1, auto x2, auto x3> when instantiated with three elements.  This is=
=20
what I mean when I say it's consistent with the way parameter packs=20
currently work for types, where template <typename... Ts> conceptually=20
expands to template <typename T1, typename T2, typename T3>.

Idependent type deduction also means that we can have lists of=20
heterogeneous values; what syntax would you propose for the value_list=20
struct template, where each value can have a different type?  If type=20
deduction happens only once, then I don't see how you can have a list of=20
heterogeneous values.


> The alternative you provide is not exactly the same in function templates=
,=20
> because
> I can=E2=80=99t let the compiler deduce T from the other arguments:
>
> *template* <*typename* T, T... Vs> *void* func() { };
>
> func<4,5,6>(); // no way
>
>
Agreed, the current language syntax requires that you specify the type=20
somehow.  My proposal doesn't really address this scenario, but perhaps it=
=20
should.  For a proposal that would provide the functionality you're looking=
=20
for (but with different syntax), see  N3601=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3601.html>.  (I=
=20
wasn't aware of N3601 until yesterday.)


> That links also to the other proposal of the =E2=80=9Canything at all=E2=
=80=9D keyword. It=20
> seems to me that restricting
> the use of auto in this context to only non-type parameters is a bit=20
> stretched. It=E2=80=99s as if the auto
> keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=80=
=99:
>
> auto i =3D 42; // Not allowed: you can use auto only for non-int values.
>
> Can you imagine it?
>

I think that analogy is a bit contrived, but I agree that having an=20
"anything at all" concept could be desirable.  For now, I think that=20
concept is beyond the scope of my proposal, but as an off-the-cuff thought,=
=20
here's one possible syntax:

template <Anything> struct anything;
anything<4> a1;   // ok: template parameter Anything is the value 4
anything<int> a2; // ok: template parameter Anything is the type int

My reason for limiting auto to introducing non-type parameters is that=20
that's the meaning auto already has in other contexts.  There is no present=
=20
context where auto introduces a type; it always serves as a stand-in for a=
=20
type name.

Thanks for the feedback! I appreciate the time spent to look over the=20
proposal.

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

------=_Part_567_1963516059.1420799719612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gig=
ante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><br><div>Hi.</div><div><br></div><div>I think it would be =
annoyingly inconsistent with the way auto works for variable initializers:<=
/div><div><br></div><div>auto i =3D 0, j =3D 1; // i and j must deduce to t=
he same type</div></div></blockquote><div><br>I actually don't see an incon=
sistency here.&nbsp; With variable initializers, there's only one occurrenc=
e of the keyword <font face=3D"courier new,monospace">auto<font face=3D"ari=
al,sans-serif">, but in a parameter pack declaration, there are conceptuall=
y as many occurrences as there are items in the pack, such that the declara=
tion <span style=3D"font-family: courier new,monospace;">template &lt;au</s=
pan></font>to... xs&gt;</font> expands to <span style=3D"font-family: couri=
er new,monospace;">template &lt;auto x1, auto x2, auto x3&gt;</span> when i=
nstantiated with three elements.&nbsp; This is what I mean when I say it's =
consistent with the way parameter packs currently work for types, where <sp=
an style=3D"font-family: courier new,monospace;">template &lt;typename... T=
s&gt;</span> conceptually expands to <span style=3D"font-family: courier ne=
w,monospace;">template &lt;typename T1, typename T2, typename T3&gt;</span>=
..<br><br>Idependent type deduction also means that we can have lists of het=
erogeneous values; what syntax would you propose for the <span style=3D"fon=
t-family: courier new,monospace;">value_list</span> struct template, where =
each value can have a different type?&nbsp; If type deduction happens only =
once, then I don't see how you can have a list of heterogeneous values.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-w=
rap:break-word"><div><br></div><div>The alternative you provide is not exac=
tly the same in function templates, because</div><div>I can=E2=80=99t let t=
he compiler deduce T from the other arguments:</div><div><br></div><div><b =
style=3D"font-family:'courier new',monospace">template</b><span style=3D"fo=
nt-family:'courier new',monospace">&nbsp;</span><span style=3D"font-family:=
'courier new',monospace">&lt;</span><b style=3D"font-family:'courier new',m=
onospace">typename</b><span style=3D"font-family:'courier new',monospace">&=
nbsp;</span><span style=3D"font-family:'courier new',monospace">T, T... Vs&=
gt;</span><span style=3D"font-family:'courier new',monospace">&nbsp;</span>=
<b style=3D"font-family:'courier new',monospace">void</b><span style=3D"fon=
t-family:'courier new',monospace">&nbsp;func() { };</span><br><br>func&lt;4=
,5,6&gt;(); // no way</div><div><br></div></div></blockquote><div><br>Agree=
d, the current language syntax requires that you specify the type somehow.&=
nbsp; My proposal doesn't really address this scenario, but perhaps it shou=
ld.&nbsp; For a proposal that would provide the functionality you're lookin=
g for (but with different syntax), see&nbsp; <a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2013/n3601.html">N3601</a>.&nbsp; (I wasn't=
 aware of N3601 until yesterday.)<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div style=3D"word-wrap:break-word"><div></div><div><br></=
div><div>That links also to the other proposal of the =E2=80=9Canything at =
all=E2=80=9D keyword. It seems to me that restricting</div><div>the use of =
auto in this context to only non-type parameters is a bit stretched. It=E2=
=80=99s as if the auto</div><div>keyword in C++11 was allowed to deduce any=
 type except =E2=80=98int=E2=80=99:</div><div><br></div><div>auto i =3D 42;=
 // Not allowed: you can use auto only for non-int values.</div><div><br></=
div><div>Can you imagine it?</div></div></blockquote><div><br>I think that =
analogy is a bit contrived, but I agree that having an "anything at all" co=
ncept could be desirable.&nbsp; For now, I think that concept is beyond the=
 scope of my proposal, but as an off-the-cuff thought, here's one possible =
syntax:<br><br><span style=3D"font-family: courier new,monospace;">template=
 &lt;Anything&gt; struct anything;<br>anything&lt;4&gt; a1;&nbsp;&nbsp; // =
ok: template parameter Anything is the value 4<br>anything&lt;int&gt; a2; /=
/ ok: template parameter Anything is the type int<br><span style=3D"font-fa=
mily: arial,sans-serif;"><br>My reason for limiting <span style=3D"font-fam=
ily: courier new,monospace;">auto</span> to introducing non-type parameters=
 is that that's the meaning <span style=3D"font-family: courier new,monospa=
ce;">auto</span> already has in other contexts.&nbsp; There is no present c=
ontext where auto introduces a type; it always serves as a stand-in for a t=
ype name.<br></span><br><span style=3D"font-family: arial,sans-serif;">Than=
ks for the feedback!</span></span>  I appreciate the time spent to look ove=
r the proposal.<span style=3D"font-family: courier new,monospace;"><br></sp=
an></div></div>

<p></p>

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

------=_Part_567_1963516059.1420799719612--
------=_Part_566_404263360.1420799719612--

.

------=_Part_630_503317926.1420826370848
Content-Type: multipart/alternative;
 boundary="----=_Part_631_326296749.1420826370849"

------=_Part_631_326296749.1420826370849
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think that your version is better than N3601, have less syntax noise and=
=20
more consistent with rest of language.
Only small limitation of your version is need of use `decltype` to get type=
=20
of parameter.

Problem with deduction is solvable:
template <typename T, T... Vs> void func(); //we want call it like f<1,2,3>
this could be implemented using concepts and `requires`:
template <auto... T> requires SameType<decltype(T)...> void func()

Another thing is possible future extension for `Anything` parameters. In=20
your case we could use `using` in place of `auto` and most of reasoning=20
don't change (`using` toady is used for function and types). In N3601 we=20
probably need introduce new syntax to add that.


BTW I think you should add more examples of member pointers/functions like=
=20
in N3601 because they are benefiting most from `auto` template parameters.



On Friday, January 9, 2015 at 11:35:19 AM UTC+1, bek...@gmail.com wrote:
>
> On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wrote:
>>
>>
>> Hi.
>>
>> I think it would be annoyingly inconsistent with the way auto works for=
=20
>> variable initializers:
>>
>> auto i =3D 0, j =3D 1; // i and j must deduce to the same type
>>
>
> I actually don't see an inconsistency here.  With variable initializers,=
=20
> there's only one occurrence of the keyword auto, but in a parameter pack=
=20
> declaration, there are conceptually as many occurrences as there are item=
s=20
> in the pack, such that the declaration template <auto... xs> expands to t=
emplate=20
> <auto x1, auto x2, auto x3> when instantiated with three elements.  This=
=20
> is what I mean when I say it's consistent with the way parameter packs=20
> currently work for types, where template <typename... Ts> conceptually=20
> expands to template <typename T1, typename T2, typename T3>.
>
> Idependent type deduction also means that we can have lists of=20
> heterogeneous values; what syntax would you propose for the value_list=20
> struct template, where each value can have a different type?  If type=20
> deduction happens only once, then I don't see how you can have a list of=
=20
> heterogeneous values.
>
>
>> The alternative you provide is not exactly the same in function=20
>> templates, because
>> I can=E2=80=99t let the compiler deduce T from the other arguments:
>>
>> *template* <*typename* T, T... Vs> *void* func() { };
>>
>> func<4,5,6>(); // no way
>>
>>
> Agreed, the current language syntax requires that you specify the type=20
> somehow.  My proposal doesn't really address this scenario, but perhaps i=
t=20
> should.  For a proposal that would provide the functionality you're looki=
ng=20
> for (but with different syntax), see  N3601=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3601.html>.  (I=
=20
> wasn't aware of N3601 until yesterday.)
>
>
>> That links also to the other proposal of the =E2=80=9Canything at all=E2=
=80=9D keyword.=20
>> It seems to me that restricting
>> the use of auto in this context to only non-type parameters is a bit=20
>> stretched. It=E2=80=99s as if the auto
>> keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=
=80=99:
>>
>> auto i =3D 42; // Not allowed: you can use auto only for non-int values.
>>
>> Can you imagine it?
>>
>
> I think that analogy is a bit contrived, but I agree that having an=20
> "anything at all" concept could be desirable.  For now, I think that=20
> concept is beyond the scope of my proposal, but as an off-the-cuff though=
t,=20
> here's one possible syntax:
>
> template <Anything> struct anything;
> anything<4> a1;   // ok: template parameter Anything is the value 4
> anything<int> a2; // ok: template parameter Anything is the type int
>
> My reason for limiting auto to introducing non-type parameters is that=20
> that's the meaning auto already has in other contexts.  There is no=20
> present context where auto introduces a type; it always serves as a=20
> stand-in for a type name.
>
> Thanks for the feedback! I appreciate the time spent to look over the=20
> proposal.
>

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

------=_Part_631_326296749.1420826370849
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>I think that your version is better than N3601, have l=
ess syntax noise and more consistent with rest of language.<br>Only small l=
imitation of your version is need of use `decltype` to get type of paramete=
r.<br><br>Problem with deduction is solvable:<br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Vs</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: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//we want call it like f&lt;1,2,3&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span></div></code></div>this could be i=
mplemented using concepts and `requires`:<br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">SameType<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span></div></code></div><br>Another thing is possible f=
uture extension for `Anything` parameters. In your case we could use `using=
` in place of `auto` and most of reasoning don't change (`using` toady is u=
sed for function and types). In N3601 we probably need introduce new syntax=
 to add that.<br><br><br>BTW I think you should add more examples of member=
 pointers/functions like in N3601 because they are benefiting most from `au=
to` template parameters.<br><br><br><br>On Friday, January 9, 2015 at 11:35=
:19 AM UTC+1, bek...@gmail.com wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr">On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nic=
ola Gigante wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wor=
d-wrap:break-word"><br><div>Hi.</div><div><br></div><div>I think it would b=
e annoyingly inconsistent with the way auto works for variable initializers=
:</div><div><br></div><div>auto i =3D 0, j =3D 1; // i and j must deduce to=
 the same type</div></div></blockquote><div><br>I actually don't see an inc=
onsistency here.&nbsp; With variable initializers, there's only one occurre=
nce of the keyword <font face=3D"courier new,monospace">auto<font face=3D"a=
rial,sans-serif">, but in a parameter pack declaration, there are conceptua=
lly as many occurrences as there are items in the pack, such that the decla=
ration <span style=3D"font-family:courier new,monospace">template &lt;au</s=
pan></font>to... xs&gt;</font> expands to <span style=3D"font-family:courie=
r new,monospace">template &lt;auto x1, auto x2, auto x3&gt;</span> when ins=
tantiated with three elements.&nbsp; This is what I mean when I say it's co=
nsistent with the way parameter packs currently work for types, where <span=
 style=3D"font-family:courier new,monospace">template &lt;typename... Ts&gt=
;</span> conceptually expands to <span style=3D"font-family:courier new,mon=
ospace">template &lt;typename T1, typename T2, typename T3&gt;</span>.<br><=
br>Idependent type deduction also means that we can have lists of heterogen=
eous values; what syntax would you propose for the <span style=3D"font-fami=
ly:courier new,monospace">value_list</span> struct template, where each val=
ue can have a different type?&nbsp; If type deduction happens only once, th=
en I don't see how you can have a list of heterogeneous values.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><div><br></div><div>The alternative you provide is not exactly the same =
in function templates, because</div><div>I can=E2=80=99t let the compiler d=
educe T from the other arguments:</div><div><br></div><div><b style=3D"font=
-family:'courier new',monospace">template</b><span style=3D"font-family:'co=
urier new',monospace">&nbsp;</span><span style=3D"font-family:'courier new'=
,monospace">&lt;</span><b style=3D"font-family:'courier new',monospace">typ=
ename</b><span style=3D"font-family:'courier new',monospace">&nbsp;</span><=
span style=3D"font-family:'courier new',monospace">T, T... Vs&gt;</span><sp=
an style=3D"font-family:'courier new',monospace">&nbsp;</span><b style=3D"f=
ont-family:'courier new',monospace">void</b><span style=3D"font-family:'cou=
rier new',monospace">&nbsp;func() { };</span><br><br>func&lt;4,5,6&gt;(); /=
/ no way</div><div><br></div></div></blockquote><div><br>Agreed, the curren=
t language syntax requires that you specify the type somehow.&nbsp; My prop=
osal doesn't really address this scenario, but perhaps it should.&nbsp; For=
 a proposal that would provide the functionality you're looking for (but wi=
th different syntax), see&nbsp; <a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2013/n3601.html" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2=
Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3601.html\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGBXsR2s67viiZkWglLFCCyZktdFA';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3601.html\46sa\75D\46sntz\0751\46usg\75=
AFQjCNGBXsR2s67viiZkWglLFCCyZktdFA';return true;">N3601</a>.&nbsp; (I wasn'=
t aware of N3601 until yesterday.)<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div style=3D"word-wrap:break-word"><div></div><div><br></div>=
<div>That links also to the other proposal of the =E2=80=9Canything at all=
=E2=80=9D keyword. It seems to me that restricting</div><div>the use of aut=
o in this context to only non-type parameters is a bit stretched. It=E2=80=
=99s as if the auto</div><div>keyword in C++11 was allowed to deduce any ty=
pe except =E2=80=98int=E2=80=99:</div><div><br></div><div>auto i =3D 42; //=
 Not allowed: you can use auto only for non-int values.</div><div><br></div=
><div>Can you imagine it?</div></div></blockquote><div><br>I think that ana=
logy is a bit contrived, but I agree that having an "anything at all" conce=
pt could be desirable.&nbsp; For now, I think that concept is beyond the sc=
ope of my proposal, but as an off-the-cuff thought, here's one possible syn=
tax:<br><br><span style=3D"font-family:courier new,monospace">template &lt;=
Anything&gt; struct anything;<br>anything&lt;4&gt; a1;&nbsp;&nbsp; // ok: t=
emplate parameter Anything is the value 4<br>anything&lt;int&gt; a2; // ok:=
 template parameter Anything is the type int<br><span style=3D"font-family:=
arial,sans-serif"><br>My reason for limiting <span style=3D"font-family:cou=
rier new,monospace">auto</span> to introducing non-type parameters is that =
that's the meaning <span style=3D"font-family:courier new,monospace">auto</=
span> already has in other contexts.&nbsp; There is no present context wher=
e auto introduces a type; it always serves as a stand-in for a type name.<b=
r></span><br><span style=3D"font-family:arial,sans-serif">Thanks for the fe=
edback!</span></span>  I appreciate the time spent to look over the proposa=
l.<span style=3D"font-family:courier new,monospace"><br></span></div></div>=
</blockquote></div>

<p></p>

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

------=_Part_631_326296749.1420826370849--
------=_Part_630_503317926.1420826370848--

.

--047d7bf0c58e6c69d5050c3c4d1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I do think that deducible parameters (type or none-type) need to be
explicitly declared and separated from the rest so that it is possible to
disambiguate them in special situations:

template < <Implicit_Params>, Explicit_Params> ...;

for example:

template < < typename ...Types>, Types Values ... >
struct ConstTupple: std::tupple<Types...>{
    ConstTupple(): std::tupple<Types...>(Values ...){};
};

constexpr ConstTupple<long(1),short(2)> pair_long_short_1_2;

template < <size_t sz>,void (&foo)(int (&)[sz])>
struct array_proc;

void foo5(int (&) [5]);

array_proc<foo5> array_proc5;

regards,
FM.

2015-01-09 21:29 GMT+03:30 <inkwizytoryankes@gmail.com>:

>
> I think that your version is better than N3601, have less syntax noise an=
d
> more consistent with rest of language.
> Only small limitation of your version is need of use `decltype` to get
> type of parameter.
>
> Problem with deduction is solvable:
> template <typename T, T... Vs> void func(); //we want call it like
> f<1,2,3>
> this could be implemented using concepts and `requires`:
> template <auto... T> requires SameType<decltype(T)...> void func()
>
> Another thing is possible future extension for `Anything` parameters. In
> your case we could use `using` in place of `auto` and most of reasoning
> don't change (`using` toady is used for function and types). In N3601 we
> probably need introduce new syntax to add that.
>
>
> BTW I think you should add more examples of member pointers/functions lik=
e
> in N3601 because they are benefiting most from `auto` template parameters=
..
>
>
>
>
> On Friday, January 9, 2015 at 11:35:19 AM UTC+1, bek...@gmail.com wrote:
>>
>> On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wrote:
>>>
>>>
>>> Hi.
>>>
>>> I think it would be annoyingly inconsistent with the way auto works for
>>> variable initializers:
>>>
>>> auto i =3D 0, j =3D 1; // i and j must deduce to the same type
>>>
>>
>> I actually don't see an inconsistency here.  With variable initializers,
>> there's only one occurrence of the keyword auto, but in a parameter pack
>> declaration, there are conceptually as many occurrences as there are ite=
ms
>> in the pack, such that the declaration template <auto... xs> expands to =
template
>> <auto x1, auto x2, auto x3> when instantiated with three elements.  This
>> is what I mean when I say it's consistent with the way parameter packs
>> currently work for types, where template <typename... Ts> conceptually
>> expands to template <typename T1, typename T2, typename T3>.
>>
>> Idependent type deduction also means that we can have lists of
>> heterogeneous values; what syntax would you propose for the value_list
>> struct template, where each value can have a different type?  If type
>> deduction happens only once, then I don't see how you can have a list of
>> heterogeneous values.
>>
>>
>>> The alternative you provide is not exactly the same in function
>>> templates, because
>>> I can=E2=80=99t let the compiler deduce T from the other arguments:
>>>
>>> *template* <*typename* T, T... Vs> *void* func() { };
>>>
>>> func<4,5,6>(); // no way
>>>
>>>
>> Agreed, the current language syntax requires that you specify the type
>> somehow.  My proposal doesn't really address this scenario, but perhaps =
it
>> should.  For a proposal that would provide the functionality you're look=
ing
>> for (but with different syntax), see  N3601
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3601.html>.
>> (I wasn't aware of N3601 until yesterday.)
>>
>>
>>> That links also to the other proposal of the =E2=80=9Canything at all=
=E2=80=9D keyword.
>>> It seems to me that restricting
>>> the use of auto in this context to only non-type parameters is a bit
>>> stretched. It=E2=80=99s as if the auto
>>> keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=
=80=99:
>>>
>>> auto i =3D 42; // Not allowed: you can use auto only for non-int values=
..
>>>
>>> Can you imagine it?
>>>
>>
>> I think that analogy is a bit contrived, but I agree that having an
>> "anything at all" concept could be desirable.  For now, I think that
>> concept is beyond the scope of my proposal, but as an off-the-cuff thoug=
ht,
>> here's one possible syntax:
>>
>> template <Anything> struct anything;
>> anything<4> a1;   // ok: template parameter Anything is the value 4
>> anything<int> a2; // ok: template parameter Anything is the type int
>>
>> My reason for limiting auto to introducing non-type parameters is that
>> that's the meaning auto already has in other contexts.  There is no
>> present context where auto introduces a type; it always serves as a
>> stand-in for a type name.
>>
>> Thanks for the feedback! I appreciate the time spent to look over the
>> proposal.
>>
>  --

---
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
how am I supposed to end the twisted road of  your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!

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

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

<div dir=3D"rtl"><div dir=3D"ltr">I do think that deducible parameters (typ=
e or none-type) need to be explicitly declared and separated from the rest =
so that it is possible to disambiguate them in special situations:</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">template &lt; &lt;Implicit_Params&=
gt;, Explicit_Params&gt; ...;</div><div dir=3D"ltr"><br></div><div dir=3D"l=
tr">for example:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">template =
&lt; &lt; typename ...Types&gt;, Types Values ... &gt;</div><div dir=3D"ltr=
">struct ConstTupple: std::tupple&lt;Types...&gt;{</div><div dir=3D"ltr">=
=C2=A0 =C2=A0 ConstTupple():=C2=A0std::tupple&lt;Types...&gt;(Values ...){}=
;</div><div dir=3D"ltr">};</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
>constexpr ConstTupple&lt;long(1),short(2)&gt; pair_long_short_1_2;</div><d=
iv dir=3D"ltr"><br></div><div dir=3D"ltr">template &lt; &lt;size_t sz&gt;,v=
oid (&amp;foo)(int (&amp;)[sz])&gt;</div><div dir=3D"ltr">struct array_proc=
;</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">void foo5(int (&amp;) [5=
]);</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">array_proc&lt;foo5&gt;=
 array_proc5;</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">regards,</di=
v><div dir=3D"ltr">FM.</div></div><div class=3D"gmail_extra"><div dir=3D"lt=
r"><br><div class=3D"gmail_quote">2015-01-09 21:29 GMT+03:30  <span dir=3D"=
ltr">&lt;<a href=3D"mailto:inkwizytoryankes@gmail.com" target=3D"_blank">in=
kwizytoryankes@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<br>I think that your version is better than N3601, have less syntax noise =
and more consistent with rest of language.<br>Only small limitation of your=
 version is need of use `decltype` to get type of parameter.<br><br>Problem=
 with deduction is solvable:<br><div style=3D"background-color:rgb(250,250,=
250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word=
-wrap:break-word"><code><div><span style=3D"color:#008">template</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span =
style=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> T</span><span s=
tyle=3D"color:#660">...</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#606">Vs</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> func</span><span style=3D"color:#660">();</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#800">//we want call it like =
f&lt;1,2,3&gt;</span><span style=3D"color:#000"><br></span></div></code></d=
iv>this could be implemented using concepts and `requires`:<br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">template</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">&lt;</span><span style=3D"color:#008">auto</span><span st=
yle=3D"color:#660">...</span><span style=3D"color:#000"> T</span><span styl=
e=3D"color:#660">&gt;</span><span style=3D"color:#000"> requires </span><sp=
an style=3D"color:#606">SameType</span><span style=3D"color:#660">&lt;</spa=
n><span style=3D"color:#008">decltype</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000">T</span><span style=3D"color:#660">)...&gt;<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">void</s=
pan><span style=3D"color:#000"> func</span><span style=3D"color:#660">()</s=
pan></div></code></div><br>Another thing is possible future extension for `=
Anything` parameters. In your case we could use `using` in place of `auto` =
and most of reasoning don&#39;t change (`using` toady is used for function =
and types). In N3601 we probably need introduce new syntax to add that.<br>=
<br><br>BTW I think you should add more examples of member pointers/functio=
ns like in N3601 because they are benefiting most from `auto` template para=
meters.<div><div class=3D"h5"><br><br><br><br>On Friday, January 9, 2015 at=
 11:35:19 AM UTC+1, <a href=3D"mailto:bek...@gmail.com" target=3D"_blank">b=
ek...@gmail.com</a> wrote:<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">On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><br><div>Hi.</div><div><br></div><div>I think it would be annoyingly in=
consistent with the way auto works for variable initializers:</div><div><br=
></div><div>auto i =3D 0, j =3D 1; // i and j must deduce to the same type<=
/div></div></blockquote><div><br>I actually don&#39;t see an inconsistency =
here.=C2=A0 With variable initializers, there&#39;s only one occurrence of =
the keyword <font face=3D"courier new,monospace">auto<font face=3D"arial,sa=
ns-serif">, but in a parameter pack declaration, there are conceptually as =
many occurrences as there are items in the pack, such that the declaration =
<span style=3D"font-family:courier new,monospace">template &lt;au</span></f=
ont>to... xs&gt;</font> expands to <span style=3D"font-family:courier new,m=
onospace">template &lt;auto x1, auto x2, auto x3&gt;</span> when instantiat=
ed with three elements.=C2=A0 This is what I mean when I say it&#39;s consi=
stent with the way parameter packs currently work for types, where <span st=
yle=3D"font-family:courier new,monospace">template &lt;typename... Ts&gt;</=
span> conceptually expands to <span style=3D"font-family:courier new,monosp=
ace">template &lt;typename T1, typename T2, typename T3&gt;</span>.<br><br>=
Idependent type deduction also means that we can have lists of heterogeneou=
s values; what syntax would you propose for the <span style=3D"font-family:=
courier new,monospace">value_list</span> struct template, where each value =
can have a different type?=C2=A0 If type deduction happens only once, then =
I don&#39;t see how you can have a list of heterogeneous values.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><div><br></div><div>The alternative you provide is not exactly the same=
 in function templates, because</div><div>I can=E2=80=99t let the compiler =
deduce T from the other arguments:</div><div><br></div><div><b style=3D"fon=
t-family:&#39;courier new&#39;,monospace">template</b><span style=3D"font-f=
amily:&#39;courier new&#39;,monospace">=C2=A0</span><span style=3D"font-fam=
ily:&#39;courier new&#39;,monospace">&lt;</span><b style=3D"font-family:&#3=
9;courier new&#39;,monospace">typename</b><span style=3D"font-family:&#39;c=
ourier new&#39;,monospace">=C2=A0</span><span style=3D"font-family:&#39;cou=
rier new&#39;,monospace">T, T... Vs&gt;</span><span style=3D"font-family:&#=
39;courier new&#39;,monospace">=C2=A0</span><b style=3D"font-family:&#39;co=
urier new&#39;,monospace">void</b><span style=3D"font-family:&#39;courier n=
ew&#39;,monospace">=C2=A0func() { };</span><br><br>func&lt;4,5,6&gt;(); // =
no way</div><div><br></div></div></blockquote><div><br>Agreed, the current =
language syntax requires that you specify the type somehow.=C2=A0 My propos=
al doesn&#39;t really address this scenario, but perhaps it should.=C2=A0 F=
or a proposal that would provide the functionality you&#39;re looking for (=
but with different syntax), see=C2=A0 <a href=3D"http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2013/n3601.html" target=3D"_blank">N3601</a>.=C2=
=A0 (I wasn&#39;t aware of N3601 until yesterday.)<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div></div=
><div><br></div><div>That links also to the other proposal of the =E2=80=9C=
anything at all=E2=80=9D keyword. It seems to me that restricting</div><div=
>the use of auto in this context to only non-type parameters is a bit stret=
ched. It=E2=80=99s as if the auto</div><div>keyword in C++11 was allowed to=
 deduce any type except =E2=80=98int=E2=80=99:</div><div><br></div><div>aut=
o i =3D 42; // Not allowed: you can use auto only for non-int values.</div>=
<div><br></div><div>Can you imagine it?</div></div></blockquote><div><br>I =
think that analogy is a bit contrived, but I agree that having an &quot;any=
thing at all&quot; concept could be desirable.=C2=A0 For now, I think that =
concept is beyond the scope of my proposal, but as an off-the-cuff thought,=
 here&#39;s one possible syntax:<br><br><span style=3D"font-family:courier =
new,monospace">template &lt;Anything&gt; struct anything;<br>anything&lt;4&=
gt; a1;=C2=A0=C2=A0 // ok: template parameter Anything is the value 4<br>an=
ything&lt;int&gt; a2; // ok: template parameter Anything is the type int<br=
><span style=3D"font-family:arial,sans-serif"><br>My reason for limiting <s=
pan style=3D"font-family:courier new,monospace">auto</span> to introducing =
non-type parameters is that that&#39;s the meaning <span style=3D"font-fami=
ly:courier new,monospace">auto</span> already has in other contexts.=C2=A0 =
There is no present context where auto introduces a type; it always serves =
as a stand-in for a type name.<br></span><br><span style=3D"font-family:ari=
al,sans-serif">Thanks for the feedback!</span></span>  I appreciate the tim=
e spent to look over the proposal.<span style=3D"font-family:courier new,mo=
nospace"><br></span></div></div></blockquote></div></div></blockquote></div=
><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gma=
il_signature"><div dir=3D"ltr">how am I supposed to end the twisted road of=
=C2=A0 your hair in the dark night??<br>unless the candle of your face does=
 turn a lamp up on my way!!!<br></div></div>
</div>

<p></p>

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

--047d7bf0c58e6c69d5050c3c4d1f--

.

------=_Part_773_1260025272.1420830948850
Content-Type: multipart/alternative;
 boundary="----=_Part_774_908503437.1420830948850"

------=_Part_774_908503437.1420830948850
Content-Type: text/plain; charset=UTF-8



On Friday, January 9, 2015 at 2:01:36 AM UTC-5, Arthur O'Dwyer wrote:


>
> The "Impact on the Standard" section seems a bit too one-sided. ;)  Can
> you consider and address any concerns that might come up re: opportunity
> costs of standardizing *this* meaning for template<auto> as opposed to any
> other meaning that might come along later?  Particularly, I wonder whether
> there's any chance of getting a syntax for "template on a thing and I don't
> care what kind of thing it is", such that one could write
>
>     template<anything x> size_t SizeOf = sizeof(x);
>     auto one = SizeOf<char>;  // 'anything' is here a synonym for
> 'typename'
>     auto four = SizeOf<42>;  // 'anything' is here a synonym for 'int'
>
>     template<anything f, anything... x> using Apply = f<x...>;
>     using beta = Apply<std::array, int, 3>;  // the first 'anything' is
> here a synonym for 'template<typename, size_t> class'
>
> Would this proposal, if adopted, block any possibility of using auto for
> the keyword I'm calling anything above?
> On the other hand, modern C++ seems to gravitate toward using as the
> keyword for "anything, don't know, don't care" (at least it can be used in
> contexts requiring either typenames or namespaces at the moment). Discuss.
> :)
>

For something I'm working on, this "anything" syntax would be incredibly
useful. It involves working with higher-order template classes that operate
on other template classes, but has to assume that all the template
arguments are either types, or all except the first are integers, or all
including the first, and then examples like std::array are still left in
the dark. It seems like allowing "auto" in a template context to refer to a
value or a type would allow the OP's ideal as well as mine. But might it
cause undo ambiguity in parsing dependent expressions, or could the
compiler trivially sort it out from the context?

--

---
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_774_908503437.1420830948850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 9, 2015 at 2:01:36 AM UTC-5, Ar=
thur O'Dwyer wrote:<div>&nbsp;</div><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><br></div><div>The "Impact on the Standard" sec=
tion seems a bit too one-sided. ;) &nbsp;Can you consider and address any c=
oncerns that might come up re: opportunity costs of standardizing *this* me=
aning for template&lt;auto&gt; as opposed to any other meaning that might c=
ome along later? &nbsp;Particularly, I wonder whether there's any chance of=
 getting a syntax for "template on a thing and I don't care what kind of th=
ing it is", such that one could write</div><div><br></div><div>&nbsp; &nbsp=
; template&lt;anything x&gt; size_t SizeOf =3D sizeof(x);</div><div>&nbsp; =
&nbsp; auto one =3D SizeOf&lt;char&gt;; &nbsp;// 'anything' is here a synon=
ym for 'typename'</div><div>&nbsp; &nbsp; auto four =3D SizeOf&lt;42&gt;; &=
nbsp;// 'anything' is here a synonym for 'int'</div><div><br></div><div>&nb=
sp; &nbsp; template&lt;anything f, anything... x&gt; using Apply =3D f&lt;x=
....&gt;;</div><div>&nbsp; &nbsp; using beta =3D Apply&lt;std::array, int, 3=
&gt;; &nbsp;// the first 'anything' is here a synonym for 'template&lt;type=
name, size_t&gt; class'<br></div><div><br></div><div>Would this proposal, i=
f adopted, block any possibility of using <font face=3D"courier new, monosp=
ace">auto</font> for the keyword I'm calling&nbsp;<font face=3D"courier new=
, monospace">anything</font>&nbsp;above?</div><div>On the other hand, moder=
n C++ seems to gravitate toward <font face=3D"courier new, monospace">using=
</font> as the keyword for "anything, don't know, don't care" (at least it =
can be used in contexts requiring either typenames or namespaces at the mom=
ent). Discuss. :)</div></div></blockquote><div><br></div><div>For something=
 I'm working on, this "anything" syntax would be incredibly useful. It invo=
lves working with higher-order template classes that operate on other templ=
ate classes, but has to assume that all the template arguments are either t=
ypes, or all except the first are integers, or all including the first, and=
 then examples like std::array are still left in the dark. It seems like al=
lowing "auto" in a template context to refer to a value or a type would all=
ow the OP's ideal as well as mine. But might it cause undo ambiguity in par=
sing dependent expressions, or could the compiler trivially sort it out fro=
m the context?</div></div>

<p></p>

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

------=_Part_774_908503437.1420830948850--
------=_Part_773_1260025272.1420830948850--

.

------=_Part_1160_2092661490.1420839704830
Content-Type: multipart/alternative;
 boundary="----=_Part_1161_2021975511.1420839704830"

------=_Part_1161_2021975511.1420839704830
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wrote:
>
>
> I think it would be annoyingly inconsistent with the way auto works for=
=20
> variable initializers:
>
> auto i =3D 0, j =3D 1; // i and j must deduce to the same type
>

I concur with Bekann (the OP): the use of 'auto' Nicola quoted isn't a=20
parallel case.
However, upon further thought, I also disagree with Bekann: template<typena=
me...=20
Ts> is ALSO not a parallel case!

    template<typename... Ts>  // multiple, possibly different, typenames
    template<int... Vs>  // multiple, possibly different, ints
    template<template<typename> class... Cs>  // multiple, possibly=20
different, one-type-parameter class templates
    template<template<int> class... Cs>  // multiple, possibly different,=
=20
one-int-parameter class templates

These are all existing parallel cases, completely fill the space, and=20
there's no room left for

    template<auto... As>  // multiple, possibly different, (what?)s

After further thought, I'm coming down strongly with the opinion that=20
replacing "(what?)" with "value" is simply not a good idea.
I *do* concur with Bekann that 'auto' currently strongly implies 'value';=
=20
but I am strongly of the opinion that having a syntax for "anything" would=
=20
be great, and it might not be a good idea to use up 'auto' until that other=
=20
syntax is agreed upon. (Which, yeah, might never happen. That's the=20
downside.)


Nicola continues:

> Then we have non-type parameters which have distinct type, at type level.=
=20
> So at type level
> we have only a bunch of basic types-of-type available, without the abilit=
y=20
> to form more complex
> types from these ones: bool, char, int ecc=E2=80=A6 together with typenam=
e and=20
> template template parameters.
>
> So when you say =E2=80=9Ctypename=E2=80=9D you=E2=80=99re not allowing he=
terogeneous values. The=20
> =E2=80=9Cvalues=E2=80=9D, which are the
> types, have all the same kind.
>
> That links also to the other proposal of the =E2=80=9Canything at all=E2=
=80=9D keyword. It=20
> seems to me that restricting
> the use of auto in this context to only non-type parameters is a bit=20
> stretched. It=E2=80=99s as if the auto
> keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=80=
=99:
>

You're talking about "[template] type parameters" and "[template] non-type=
=20
parameters" as if those are the only options, but they're not. Don't forget=
=20
about "template template parameters". That's the biggest use-case for the=
=20
"anything" feature.  Again I'll mention the example of Apply<std::array,=20
int, 3> =E2=80=94 the template parameters there are one template template=
=20
parameter, one template non-type parameter, and one template type=20
parameter, in that order. If we could just say that they were a template=20
anything parameter, a template anything parameter, and a template anything=
=20
parameter (in that order), how cool would that be?

(It wouldn't even add ambiguities, because the parser already forces you to=
=20
disambiguate certain template-dependent names with 'typename' and=20
'template'. I wouldn't propose any change to those rules.)

Lastly, even if Bekann doesn't adopt the "anything" syntax, Bekann's=20
proposal ought to explicitly include an example of the form

    // the simplest case
    template<template<auto...> class C, auto... Vs> constexpr auto gamma =
=3D=20
C<Vs...>::value;

    // the confusing case
    template<template<auto...> class... C> constexpr auto delta =3D=20
sum<C<1,2,3,4>...>::value;

    template<auto... As> class sum { static constexpr int value =3D As + ..=
..=20
+ 0; }
    template<double... Ds> class product { static constexpr int value =3D D=
s=20
* ... * 1; }
    template<int... Js> class xorprod { static constexpr int value =3D Js ^=
=20
.... ^ 1; }

    constexpr auto d1 =3D delta<sum, product>;  // does this compile?
    constexpr auto d2 =3D delta<product, xorprod>;  // does this compile?

with both "does this compile?" questions answered in some reasonable way.

Also, yeah, N3601 is awesome. Wouldn't it allow this solution to the=20
"value_list" problem that motivated the whole thing?

    template<using typename... Ts, Ts... Vs> class value_list {};
    using v =3D value_list<1, 'c', 3.14>;

=E2=80=93Arthur

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

------=_Part_1161_2021975511.1420839704830
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gig=
ante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><br><div><div>I think it would be annoyingly inconsistent =
with the way auto works for variable initializers:<br></div></div><div><br>=
</div><div>auto i =3D 0, j =3D 1; // i and j must deduce to the same type</=
div></div></blockquote><div><br></div><div>I concur with Bekann (the OP): t=
he use of 'auto' Nicola quoted isn't a parallel case.</div><div>However, up=
on further thought, I also disagree with Bekann: <font face=3D"courier new,=
 monospace">template&lt;typename... Ts&gt;</font> is ALSO not a parallel ca=
se!</div><div><br></div><div>&nbsp; &nbsp; template&lt;typename... Ts&gt; &=
nbsp;// multiple, possibly different, typenames</div><div>&nbsp; &nbsp; tem=
plate&lt;int... Vs&gt; &nbsp;// multiple, possibly different, ints</div><di=
v><div>&nbsp; &nbsp; template&lt;template&lt;typename&gt; class... Cs&gt; &=
nbsp;// multiple, possibly different, one-type-parameter class templates</d=
iv></div><div><div>&nbsp; &nbsp; template&lt;template&lt;int&gt; class... C=
s&gt; &nbsp;// multiple, possibly different, one-int-parameter class templa=
tes</div></div><div><br></div><div>These are all existing parallel cases, c=
ompletely fill the space, and there's no room left for</div><div><br></div>=
<div>&nbsp; &nbsp; template&lt;auto... As&gt; &nbsp;// multiple, possibly d=
ifferent, (what?)s</div><div><br></div><div>After further thought, I'm comi=
ng down strongly with the opinion that replacing "(what?)" with "value" is =
simply not a good idea.</div><div>I *do* concur with Bekann that 'auto' cur=
rently strongly implies 'value'; but I am strongly of the opinion that havi=
ng a syntax for "anything" would be great, and it might not be a good idea =
to use up 'auto' until that other syntax is agreed upon. (Which, yeah, migh=
t never happen. That's the downside.)</div><div><br></div><div><br></div><d=
iv>Nicola continues:</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 style=3D"word-wrap:break-word"><div>Then we have non-type parameters which=
 have distinct type, at type level. So at type level<br></div><div>we have =
only a bunch of basic types-of-type available, without the ability to form =
more complex</div><div>types from these ones: bool, char, int ecc=E2=80=A6 =
together with typename and template template parameters.</div><div><br></di=
v><div>So when you say =E2=80=9Ctypename=E2=80=9D you=E2=80=99re not allowi=
ng heterogeneous values. The =E2=80=9Cvalues=E2=80=9D, which are the</div><=
div>types, have all the same kind.</div><div><br></div><div>That links also=
 to the other proposal of the =E2=80=9Canything at all=E2=80=9D keyword. It=
 seems to me that restricting</div><div>the use of auto in this context to =
only non-type parameters is a bit stretched. It=E2=80=99s as if the auto</d=
iv><div>keyword in C++11 was allowed to deduce any type except =E2=80=98int=
=E2=80=99:</div></div></blockquote><div><br></div><div>You're talking about=
 "[template] type parameters" and "[template] non-type parameters" as if th=
ose are the only options, but they're not. Don't forget about "template tem=
plate parameters". That's the biggest use-case for the "anything" feature. =
&nbsp;Again I'll mention the example of Apply&lt;std::array, int, 3&gt; =E2=
=80=94 the template parameters there are one template template parameter, o=
ne template non-type parameter, and one template type parameter, in that or=
der. If we could just say that they were a template anything parameter, a t=
emplate anything parameter, and a template anything parameter (in that orde=
r), how cool would that be?</div><div><br></div><div>(It wouldn't even add =
ambiguities, because the parser already forces you to disambiguate certain =
template-dependent names with 'typename' and 'template'. I wouldn't propose=
 any change to those rules.)</div><div><br></div><div>Lastly, even if Bekan=
n doesn't adopt the "anything" syntax, Bekann's proposal ought to explicitl=
y include an example of the form</div><div><br></div><div>&nbsp; &nbsp; // =
the simplest case</div><div>&nbsp; &nbsp; template&lt;template&lt;auto...&g=
t; class C, auto... Vs&gt; constexpr auto gamma =3D C&lt;Vs...&gt;::value;<=
/div><div><br></div><div>&nbsp; &nbsp; // the confusing case</div><div>&nbs=
p; &nbsp; template&lt;template&lt;auto...&gt; class... C&gt; constexpr auto=
 delta =3D sum&lt;C&lt;1,2,3,4&gt;...&gt;::value;<br></div><div><br></div><=
div>&nbsp; &nbsp; template&lt;auto... As&gt; class sum { static constexpr i=
nt value =3D As + ... + 0; }</div><div></div><div>&nbsp; &nbsp; template&lt=
;double... Ds&gt; class product { static constexpr int value =3D Ds * ... *=
 1; }</div><div><div>&nbsp; &nbsp; template&lt;int... Js&gt; class xorprod =
{ static constexpr int value =3D Js ^ ... ^ 1; }</div></div><div><br></div>=
<div><div>&nbsp; &nbsp; constexpr auto d1 =3D delta&lt;sum, product&gt;; &n=
bsp;// does this compile?</div></div><div><div>&nbsp; &nbsp; constexpr auto=
 d2 =3D delta&lt;product, xorprod&gt;; &nbsp;// does this compile?</div></d=
iv><div><br></div><div>with both "does this compile?" questions answered in=
 some reasonable way.</div><div><br></div><div>Also, yeah, N3601 is awesome=
.. Wouldn't it allow this solution to the "value_list" problem that motivate=
d the whole thing?</div><div><br></div><div>&nbsp; &nbsp; template&lt;using=
 typename... Ts, Ts... Vs&gt; class value_list {};</div><div>&nbsp; &nbsp; =
using v =3D value_list&lt;1, 'c', 3.14&gt;;</div><div><br></div><div>=E2=80=
=93Arthur</div></div>

<p></p>

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

------=_Part_1161_2021975511.1420839704830--
------=_Part_1160_2092661490.1420839704830--

.

------=_Part_858_1068815898.1420841564734
Content-Type: multipart/alternative;
 boundary="----=_Part_859_2035574178.1420841564735"

------=_Part_859_2035574178.1420841564735
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Friday, January 9, 2015 at 10:41:44 PM UTC+1, Arthur O'Dwyer wrote:
>
> On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wrote:
>>
>>
>> I think it would be annoyingly inconsistent with the way auto works for=
=20
>> variable initializers:
>>
>> auto i =3D 0, j =3D 1; // i and j must deduce to the same type
>>
>
> I concur with Bekann (the OP): the use of 'auto' Nicola quoted isn't a=20
> parallel case.
> However, upon further thought, I also disagree with Bekann: template<type=
name...=20
> Ts> is ALSO not a parallel case!
>
>     template<typename... Ts>  // multiple, possibly different, typenames
>     template<int... Vs>  // multiple, possibly different, ints
>     template<template<typename> class... Cs>  // multiple, possibly=20
> different, one-type-parameter class templates
>     template<template<int> class... Cs>  // multiple, possibly different,=
=20
> one-int-parameter class templates
>
> These are all existing parallel cases, completely fill the space, and=20
> there's no room left for
>
>     template<auto... As>  // multiple, possibly different, (what?)s
>
> correct comparison should be with:
template<template<class...> class... T> // possible different sizes and=20
types
template<auto... T> // possible different types and values



=20

> After further thought, I'm coming down strongly with the opinion that=20
> replacing "(what?)" with "value" is simply not a good idea.
> I *do* concur with Bekann that 'auto' currently strongly implies 'value';=
=20
> but I am strongly of the opinion that having a syntax for "anything" woul=
d=20
> be great, and it might not be a good idea to use up 'auto' until that oth=
er=20
> syntax is agreed upon. (Which, yeah, might never happen. That's the=20
> downside.)
>
>
> Nicola continues:
>
>> Then we have non-type parameters which have distinct type, at type level=
..=20
>> So at type level
>> we have only a bunch of basic types-of-type available, without the=20
>> ability to form more complex
>> types from these ones: bool, char, int ecc=E2=80=A6 together with typena=
me and=20
>> template template parameters.
>>
>> So when you say =E2=80=9Ctypename=E2=80=9D you=E2=80=99re not allowing h=
eterogeneous values. The=20
>> =E2=80=9Cvalues=E2=80=9D, which are the
>> types, have all the same kind.
>>
>> That links also to the other proposal of the =E2=80=9Canything at all=E2=
=80=9D keyword.=20
>> It seems to me that restricting
>> the use of auto in this context to only non-type parameters is a bit=20
>> stretched. It=E2=80=99s as if the auto
>> keyword in C++11 was allowed to deduce any type except =E2=80=98int=E2=
=80=99:
>>
>
> You're talking about "[template] type parameters" and "[template] non-typ=
e=20
> parameters" as if those are the only options, but they're not. Don't forg=
et=20
> about "template template parameters". That's the biggest use-case for the=
=20
> "anything" feature.  Again I'll mention the example of Apply<std::array,=
=20
> int, 3> =E2=80=94 the template parameters there are one template template=
=20
> parameter, one template non-type parameter, and one template type=20
> parameter, in that order. If we could just say that they were a template=
=20
> anything parameter, a template anything parameter, and a template anythin=
g=20
> parameter (in that order), how cool would that be?
>
> (It wouldn't even add ambiguities, because the parser already forces you=
=20
> to disambiguate certain template-dependent names with 'typename' and=20
> 'template'. I wouldn't propose any change to those rules.)
>
> For that `using` in palace `auto` could be used if we want have bigger=20
unification. One downside would be that you could not directly use it=20
without specialization to value type param or type param.
=20

> Lastly, even if Bekann doesn't adopt the "anything" syntax, Bekann's=20
> proposal ought to explicitly include an example of the form
>
>     // the simplest case
>     template<template<auto...> class C, auto... Vs> constexpr auto gamma =
=3D=20
> C<Vs...>::value;
>
>     // the confusing case
>     template<template<auto...> class... C> constexpr auto delta =3D=20
> sum<C<1,2,3,4>...>::value;
>
>     template<auto... As> class sum { static constexpr int value =3D As + =
....=20
> + 0; }
>     template<double... Ds> class product { static constexpr int value =3D=
 Ds=20
> * ... * 1; }
>     template<int... Js> class xorprod { static constexpr int value =3D Js=
 ^=20
> ... ^ 1; }
>
>     constexpr auto d1 =3D delta<sum, product>;  // does this compile?
>     constexpr auto d2 =3D delta<product, xorprod>;  // does this compile?
>
> with both "does this compile?" questions answered in some reasonable way.
>
> You should drop `double` because is forbidden as template value. I assume=
=20
lack of `::value` after `C<1,2,3,4>` is mistype. Aside form that I don't=20
see any problem with that. It should compile.
`sum`, `product`, and `xorprod` can accept 4 arguments of type `int`. After=
=20
that we get 2 `::value` of type `int` that again can by apply to `sum`.
=20

> Also, yeah, N3601 is awesome. Wouldn't it allow this solution to the=20
> "value_list" problem that motivated the whole thing?
>
>     template<using typename... Ts, Ts... Vs> class value_list {};
>     using v =3D value_list<1, 'c', 3.14>;
>
> =E2=80=93Arthur
>

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

------=_Part_859_2035574178.1420841564735
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 9, 2015 at 10:41:44 PM UTC+1, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, January 9, 2015 at 1:55:42 AM UTC-8, Nicola Gigante wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><br><div><div>I think it would be annoyingly inconsistent with the way =
auto works for variable initializers:<br></div></div><div><br></div><div>au=
to i =3D 0, j =3D 1; // i and j must deduce to the same type</div></div></b=
lockquote><div><br></div><div>I concur with Bekann (the OP): the use of 'au=
to' Nicola quoted isn't a parallel case.</div><div>However, upon further th=
ought, I also disagree with Bekann: <font face=3D"courier new, monospace">t=
emplate&lt;typename... Ts&gt;</font> is ALSO not a parallel case!</div><div=
><br></div><div>&nbsp; &nbsp; template&lt;typename... Ts&gt; &nbsp;// multi=
ple, possibly different, typenames</div><div>&nbsp; &nbsp; template&lt;int.=
... Vs&gt; &nbsp;// multiple, possibly different, ints</div><div><div>&nbsp;=
 &nbsp; template&lt;template&lt;typename&gt; class... Cs&gt; &nbsp;// multi=
ple, possibly different, one-type-parameter class templates</div></div><div=
><div>&nbsp; &nbsp; template&lt;template&lt;int&gt; class... Cs&gt; &nbsp;/=
/ multiple, possibly different, one-int-parameter class templates</div></di=
v><div><br></div><div>These are all existing parallel cases, completely fil=
l the space, and there's no room left for</div><div><br></div><div>&nbsp; &=
nbsp; template&lt;auto... As&gt; &nbsp;// multiple, possibly different, (wh=
at?)s</div><div><br></div></div></blockquote><div>correct comparison should=
 be with:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">...&gt;</span><spa=
n 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"c=
olor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// possible different sizes and types</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// possible=
 different types and values</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br><br><br>&nbsp;</div><blo=
ckquote 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></div><div>A=
fter further thought, I'm coming down strongly with the opinion that replac=
ing "(what?)" with "value" is simply not a good idea.</div><div>I *do* conc=
ur with Bekann that 'auto' currently strongly implies 'value'; but I am str=
ongly of the opinion that having a syntax for "anything" would be great, an=
d it might not be a good idea to use up 'auto' until that other syntax is a=
greed upon. (Which, yeah, might never happen. That's the downside.)</div><d=
iv><br></div><div><br></div><div>Nicola continues:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Then we hav=
e non-type parameters which have distinct type, at type level. So at type l=
evel<br></div><div>we have only a bunch of basic types-of-type available, w=
ithout the ability to form more complex</div><div>types from these ones: bo=
ol, char, int ecc=E2=80=A6 together with typename and template template par=
ameters.</div><div><br></div><div>So when you say =E2=80=9Ctypename=E2=80=
=9D you=E2=80=99re not allowing heterogeneous values. The =E2=80=9Cvalues=
=E2=80=9D, which are the</div><div>types, have all the same kind.</div><div=
><br></div><div>That links also to the other proposal of the =E2=80=9Canyth=
ing at all=E2=80=9D keyword. It seems to me that restricting</div><div>the =
use of auto in this context to only non-type parameters is a bit stretched.=
 It=E2=80=99s as if the auto</div><div>keyword in C++11 was allowed to dedu=
ce any type except =E2=80=98int=E2=80=99:</div></div></blockquote><div><br>=
</div><div>You're talking about "[template] type parameters" and "[template=
] non-type parameters" as if those are the only options, but they're not. D=
on't forget about "template template parameters". That's the biggest use-ca=
se for the "anything" feature. &nbsp;Again I'll mention the example of Appl=
y&lt;std::array, int, 3&gt; =E2=80=94 the template parameters there are one=
 template template parameter, one template non-type parameter, and one temp=
late type parameter, in that order. If we could just say that they were a t=
emplate anything parameter, a template anything parameter, and a template a=
nything parameter (in that order), how cool would that be?</div><div><br></=
div><div>(It wouldn't even add ambiguities, because the parser already forc=
es you to disambiguate certain template-dependent names with 'typename' and=
 'template'. I wouldn't propose any change to those rules.)</div><div><br><=
/div></div></blockquote><div>For that `using` in palace `auto` could be use=
d if we want have bigger unification. One downside would be that you could =
not directly use it without specialization to value type param or type para=
m.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div></div><div>Lastly, even if Bekann doesn't adopt the "anything" sy=
ntax, Bekann's proposal ought to explicitly include an example of the form<=
/div><div><br></div><div>&nbsp; &nbsp; // the simplest case</div><div>&nbsp=
; &nbsp; template&lt;template&lt;auto...&gt; class C, auto... Vs&gt; conste=
xpr auto gamma =3D C&lt;Vs...&gt;::value;</div><div><br></div><div>&nbsp; &=
nbsp; // the confusing case</div><div>&nbsp; &nbsp; template&lt;template&lt=
;auto...&gt; class... C&gt; constexpr auto delta =3D sum&lt;C&lt;1,2,3,4&gt=
;...&gt;::value;<br></div><div><br></div><div>&nbsp; &nbsp; template&lt;aut=
o... As&gt; class sum { static constexpr int value =3D As + ... + 0; }</div=
><div></div><div>&nbsp; &nbsp; template&lt;double... Ds&gt; class product {=
 static constexpr int value =3D Ds * ... * 1; }</div><div><div>&nbsp; &nbsp=
; template&lt;int... Js&gt; class xorprod { static constexpr int value =3D =
Js ^ ... ^ 1; }</div></div><div><br></div><div><div>&nbsp; &nbsp; constexpr=
 auto d1 =3D delta&lt;sum, product&gt;; &nbsp;// does this compile?</div></=
div><div><div>&nbsp; &nbsp; constexpr auto d2 =3D delta&lt;product, xorprod=
&gt;; &nbsp;// does this compile?</div></div><div><br></div><div>with both =
"does this compile?" questions answered in some reasonable way.</div><div><=
br></div></div></blockquote><div>You should drop `double` because is forbid=
den as template value. I assume lack of `::value` after `C&lt;1,2,3,4&gt;` =
is mistype. Aside form that I don't see any problem with that. It should co=
mpile.<br>`sum`, `product`, and `xorprod` can accept 4 arguments of type `i=
nt`. After that we get 2 `::value`  of type `int` that again can by apply t=
o `sum`.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div></div><div>Also, yeah, N3601 is awesome. Wouldn't it allow =
this solution to the "value_list" problem that motivated the whole thing?</=
div><div><br></div><div>&nbsp; &nbsp; template&lt;using typename... Ts, Ts.=
... Vs&gt; class value_list {};</div><div>&nbsp; &nbsp; using v =3D value_li=
st&lt;1, 'c', 3.14&gt;;</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div>

<p></p>

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

------=_Part_859_2035574178.1420841564735--
------=_Part_858_1068815898.1420841564734--

.

------=_Part_790_2134090115.1420843583140
Content-Type: multipart/alternative;
 boundary="----=_Part_791_380690611.1420843583140"

------=_Part_791_380690611.1420843583140
Content-Type: text/plain; charset=UTF-8

OK, I think we have a pretty good idea of desired features at this point:

   - "AnyType" template value parameters (my original motivation)
   - "AnythingAtAll" template parameters
   - Template meta-parameters (what N3601 refers to as "implicit template
   parameters", but I really think it's more a way of templatizing a template)

I think all of these can peacefully coexist in the same standard.  Here's
my idea (I'll update the paper when I find some time):

*"AnyType" template value parameters:* template <auto x, auto... y> ...
Keep my proposed syntax.  I understand the desire to use auto to mean
"anything at all," but I think we need a keyword that specifically
introduces a value parameter, and auto is the only existing keyword that
fits the bill.  I would prefer something like var (in place of *all*
existing uses of auto), but that ship has long-since sailed.
*"AnythingAtAll" template parameters:* template <T, x, Templ, ... Whatever>
....
Anything parameters simply have no introducing keyword.  In this model, an
introducing keyword (typename, class, template, auto) serves to explicitly
limit the classification of the template parameter; the *absence* of such a
keyword means that the classification is determined at the point of
instantiation.  (The ellipsis inside the angle brackets introduces a
parameter pack of AnythingAtAlls.)
*Template meta-parameters:* template using typename Fn, typename T <Fn fn,
T... t> ...
This is the same as N3601, except that I've moved the using keyword outside
the parameter list to emphasize that Fn and T are not template parameters.
This keeps a 1:1 correlation between the elements of a template parameter
list and elements of argument lists at points of instantiation.  That is,
given a declaration:
template using typename R, typename... Args <R (* f)(Args...)> struct func;
....the point of use looks like:
func<MyFunc> myfunc;
....and in both cases there's only one item in the angle brackets.

In terms of functionality, this seems to cover all the bases.

--

---
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_791_380690611.1420843583140
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, I think we have a pretty good idea of desired features=
 at this point:<br><ul><li>"AnyType" template value parameters (my original=
 motivation)<br></li><li>"AnythingAtAll" template parameters</li><li>Templa=
te
 meta-parameters (what N3601 refers to as "implicit template=20
parameters", but I really think it's more a way of templatizing a=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.&nbsp; Here's my idea (I'll update the paper when I find some time=
):<br><br><b>"AnyType" template value parameters:</b> <span style=3D"font-f=
amily: courier new,monospace;">template &lt;auto x, auto... y&gt;</span> ..=
..<br><div style=3D"margin-left: 40px;">Keep my proposed syntax.&nbsp; I und=
erstand the desire to use <span style=3D"font-family: courier new,monospace=
;">auto</span>
 to mean "anything at all," but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family: =
courier new,monospace;">auto</span> is the only existing
 keyword that fits the bill.&nbsp; I would prefer something like <span styl=
e=3D"font-family: courier new,monospace;">var</span> (in place of <i>all</i=
> existing uses of <span style=3D"font-family: courier new,monospace;">auto=
</span>), but that ship has long-since sailed.<br></div><b>"AnythingAtAll" =
template parameters:</b> <span style=3D"font-family: courier new,monospace;=
">template &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=3D"ma=
rgin-left: 40px;">Anything parameters simply have no introducing keyword.&n=
bsp; In this model, an introducing keyword (<span style=3D"font-family: cou=
rier new,monospace;">typename</span>, <span style=3D"font-family: courier n=
ew,monospace;">class</span>, <span style=3D"font-family: courier new,monosp=
ace;">template</span>, <span style=3D"font-family: courier new,monospace;">=
auto</span>) serves to explicitly limit the classification of the template =
parameter; the <i>absence</i> of such a keyword means that the classificati=
on is determined at the point of instantiation.&nbsp; (The ellipsis inside =
the angle brackets introduces a parameter pack of AnythingAtAlls.)<br></div=
><b>Template
 meta-parameters:</b> <span style=3D"font-family: courier new,monospace;">t=
emplate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><=
div style=3D"margin-left: 40px;">This is the same as N3601, except that I'v=
e moved the <span style=3D"font-family: courier new,monospace;">using</span=
> keyword outside the parameter list to emphasize that <span style=3D"font-=
family: courier new,monospace;">Fn</span> and <span style=3D"font-family: c=
ourier new,monospace;">T</span> are not template parameters.&nbsp; This kee=
ps a 1:1 correlation between the elements of a template parameter list and =
elements of argument lists at points of instantiation.&nbsp; That is, given=
 a declaration:<br><div style=3D"margin-left: 40px;"><span style=3D"font-fa=
mily: courier new,monospace;">template using typename R, typename... Args &=
lt;R (* f)(Args...)&gt; struct func;</span><br></div>...the point of use lo=
oks like:<br><div style=3D"margin-left: 40px;"><span style=3D"font-family: =
courier new,monospace;">func&lt;MyFunc&gt; myfunc;</span><br></div>...and i=
n both cases there's only one item in the angle brackets.<br></div><br>In t=
erms of functionality, this seems to cover all the bases.<br></div>

<p></p>

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

------=_Part_791_380690611.1420843583140--
------=_Part_790_2134090115.1420843583140--

.

------=_Part_1231_1595321734.1420844456135
Content-Type: multipart/alternative;
 boundary="----=_Part_1232_1239050543.1420844456135"

------=_Part_1232_1239050543.1420844456135
Content-Type: text/plain; charset=UTF-8



On Friday, January 9, 2015 at 11:46:23 PM UTC+1, bek...@gmail.com wrote:
>
> OK, I think we have a pretty good idea of desired features at this point:
>
>    - "AnyType" template value parameters (my original motivation)
>    - "AnythingAtAll" template parameters
>    - Template meta-parameters (what N3601 refers to as "implicit template
>    parameters", but I really think it's more a way of templatizing a template)
>
> I think all of these can peacefully coexist in the same standard.  Here's
> my idea (I'll update the paper when I find some time):
>
> *"AnyType" template value parameters:* template <auto x, auto... y> ...
> Keep my proposed syntax.  I understand the desire to use auto to mean
> "anything at all," but I think we need a keyword that specifically
> introduces a value parameter, and auto is the only existing keyword that
> fits the bill.  I would prefer something like var (in place of *all*
> existing uses of auto), but that ship has long-since sailed.
> *"AnythingAtAll" template parameters:* template <T, x, Templ, ...
> Whatever> ...
> Anything parameters simply have no introducing keyword.  In this model, an
> introducing keyword (typename, class, template, auto) serves to
> explicitly limit the classification of the template parameter; the
> *absence* of such a keyword means that the classification is determined
> at the point of instantiation.  (The ellipsis inside the angle brackets
> introduces a parameter pack of AnythingAtAlls.)
>

Do you consider using `using` as keyword?
some thing like that:
template<using All, using... AllMultiple>
This will prevent code breaks when someone introduce new type that is same
like name in template parameter. e.g.
class T {};
template<T> class Z {}; //valid code today





> *Template meta-parameters:* template using typename Fn, typename T <Fn
> fn, T... t> ...
> This is the same as N3601, except that I've moved the using keyword
> outside the parameter list to emphasize that Fn and T are not template
> parameters.  This keeps a 1:1 correlation between the elements of a
> template parameter list and elements of argument lists at points of
> instantiation.  That is, given a declaration:
> template using typename R, typename... Args <R (* f)(Args...)> struct func;
> ...the point of use looks like:
> func<MyFunc> myfunc;
> ...and in both cases there's only one item in the angle brackets.
>
> In terms of functionality, this seems to cover all the bases.
>

I don't think its is require. `auto` and specialization could do this too:
template<auto X> struct func = delete; //only used as proxy
template<typename R, typename... Args> struct func<R (* f)(Args...)> struct
func { };


--

---
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_1232_1239050543.1420844456135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 9, 2015 at 11:46:23 PM UTC+1, b=
ek...@gmail.com wrote:<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">OK, I think we have a pretty good idea of desired features at this=
 point:<br><ul><li>"AnyType" template value parameters (my original motivat=
ion)<br></li><li>"AnythingAtAll" template parameters</li><li>Template
 meta-parameters (what N3601 refers to as "implicit template=20
parameters", but I really think it's more a way of templatizing a=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.&nbsp; Here's my idea (I'll update the paper when I find some time=
):<br><br><b>"AnyType" template value parameters:</b> <span style=3D"font-f=
amily:courier new,monospace">template &lt;auto x, auto... y&gt;</span> ...<=
br><div style=3D"margin-left:40px">Keep my proposed syntax.&nbsp; I underst=
and the desire to use <span style=3D"font-family:courier new,monospace">aut=
o</span>
 to mean "anything at all," but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family:c=
ourier new,monospace">auto</span> is the only existing
 keyword that fits the bill.&nbsp; I would prefer something like <span styl=
e=3D"font-family:courier new,monospace">var</span> (in place of <i>all</i> =
existing uses of <span style=3D"font-family:courier new,monospace">auto</sp=
an>), but that ship has long-since sailed.<br></div><b>"AnythingAtAll" temp=
late parameters:</b> <span style=3D"font-family:courier new,monospace">temp=
late &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=3D"margin-l=
eft:40px">Anything parameters simply have no introducing keyword.&nbsp; In =
this model, an introducing keyword (<span style=3D"font-family:courier new,=
monospace">typename</span>, <span style=3D"font-family:courier new,monospac=
e">class</span>, <span style=3D"font-family:courier new,monospace">template=
</span>, <span style=3D"font-family:courier new,monospace">auto</span>) ser=
ves to explicitly limit the classification of the template parameter; the <=
i>absence</i> of such a keyword means that the classification is determined=
 at the point of instantiation.&nbsp; (The ellipsis inside the angle bracke=
ts introduces a parameter pack of AnythingAtAlls.)<br></div></div></blockqu=
ote><div><br>Do you consider using `using` as keyword?<br>some thing like t=
hat:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">All</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">using</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">AllMultiple</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span></div></code></div>This will prevent code breaks when someon=
e introduce new type that is same like name in template parameter. e.g.<br>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><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 s=
tyle=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=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> Z </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">//valid code today</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br><br><br>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div style=3D"margin-left:40px"></div><b>Templat=
e
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><di=
v style=3D"margin-left:40px">This is the same as N3601, except that I've mo=
ved the <span style=3D"font-family:courier new,monospace">using</span> keyw=
ord outside the parameter list to emphasize that <span style=3D"font-family=
:courier new,monospace">Fn</span> and <span style=3D"font-family:courier ne=
w,monospace">T</span> are not template parameters.&nbsp; This keeps a 1:1 c=
orrelation between the elements of a template parameter list and elements o=
f argument lists at points of instantiation.&nbsp; That is, given a declara=
tion:<br><div style=3D"margin-left:40px"><span style=3D"font-family:courier=
 new,monospace">template using typename R, typename... Args &lt;R (* f)(Arg=
s...)&gt; struct func;</span><br></div>...the point of use looks like:<br><=
div style=3D"margin-left:40px"><span style=3D"font-family:courier new,monos=
pace">func&lt;MyFunc&gt; myfunc;</span><br></div>...and in both cases there=
's only one item in the angle brackets.<br></div><br>In terms of functional=
ity, this seems to cover all the bases.<br></div></blockquote><div>&nbsp;</=
div><div>I don't think its is require. `auto` and specialization could do t=
his too:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> X</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=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> func </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">delete</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: #800;" class=3D"styled-by-prettify">//only =
used as proxy</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> R</span><spa=
n 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">typename</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: #606;" class=3D"=
styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">s=
truct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> func=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">R </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)(</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">...)&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> func </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"styled-by-prettify">};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><br><br></div></div>

<p></p>

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

------=_Part_1232_1239050543.1420844456135--
------=_Part_1231_1595321734.1420844456135--

.

------=_Part_888_892259344.1420845023579
Content-Type: multipart/alternative;
 boundary="----=_Part_889_324487607.1420845023579"

------=_Part_889_324487607.1420845023579
Content-Type: text/plain; charset=UTF-8

On Friday, January 9, 2015 at 3:00:56 PM UTC-8, inkwizyt...@gmail.com wrote:
>
> Do you consider using `using` as keyword?
> some thing like that:
> template<using All, using... AllMultiple>
>

It's a possibility; I wanted to avoid overloading using  in this way
because I think it doesn't read as nicely, but that's a bikeshedding
conversation; I'm more concerned that the syntax allows for all of the
stated functionality (and either choice does).

This will prevent code breaks when someone introduce new type that is same
> like name in template parameter. e.g.
> class T {};
> template<T> class Z {}; //valid code today
>
>
That's a good point that I hadn't considered.  I'll think on that.


> *Template meta-parameters:* template using typename Fn, typename T <Fn
>> fn, T... t> ...
>>
> I don't think its is require. `auto` and specialization could do this too:
> template<auto X> struct func = delete; //only used as proxy
> template<typename R, typename... Args> struct func<R (* f)(Args...)>
> struct func { };
>
>
That works fine for class templates (and is in fact the approach I took for
my paper), but not for function templates.  I think template
meta-parameters do a nice job of increasing flexibility while reducing
noise.  They also cover the typed_value_list scenario above:

template using typename T <T... ts> struct typed_value_list;

--

---
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_889_324487607.1420845023579
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 9, 2015 at 3:00:56 PM UTC-8, inkwizyt..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Do you consider using `using` as keyword?<br><div>some thing like that=
:<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;=
</span><span style=3D"color:#008">using</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#606">All</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">using</spa=
n><span style=3D"color:#660">...</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">AllMultiple</span><span style=3D"color:#660">&gt;=
</span></div></code></div></div></div></blockquote><div><br>It's a possibil=
ity; I wanted to avoid overloading <span style=3D"font-family: courier new,=
monospace;">using</span>&nbsp; in this way because I think it doesn't read =
as nicely, but that's a bikeshedding conversation; I'm more concerned that =
the syntax allows for all of the stated functionality (and either choice do=
es).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>This will prevent code breaks when someone introduce new type tha=
t is same like name in template parameter. e.g.<br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">=
class</span><span style=3D"color:#000"> T </span><span style=3D"color:#660"=
>{};</span><span style=3D"color:#000"><br></span><span style=3D"color:#008"=
>template</span><span style=3D"color:#660">&lt;</span><span style=3D"color:=
#000">T</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">class</span><span style=3D"color:#00=
0"> Z </span><span style=3D"color:#660">{};</span><span style=3D"color:#000=
"> </span><span style=3D"color:#800">//valid code today</span><span style=
=3D"color:#000"><br></span></div></code></div><br></div></div></blockquote>=
<div><br>That's a good point that I hadn't considered.&nbsp; I'll think on =
that.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><b>Templa=
te
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ... <br></=
div></blockquote><div>I don't think its is require. `auto` and specializati=
on could do this too:<br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:#008">template</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#000"> X</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> func </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">delete</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D=
"color:#800">//only used as proxy</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#008">template</span><span style=3D"color:#660">&lt=
;</span><span style=3D"color:#008">typename</span><span style=3D"color:#000=
"> R</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">typename</span><span style=3D"color:#660">=
....</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Arg=
s</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">struct</span><span style=3D"color:#000"> f=
unc</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">=
R </span><span style=3D"color:#660">(*</span><span style=3D"color:#000"> f<=
/span><span style=3D"color:#660">)(</span><span style=3D"color:#606">Args</=
span><span style=3D"color:#660">...)&gt;</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">struct</span><span style=3D"color:#000"> =
func </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><=
/span></div></code></div><br></div></div></blockquote><div><br>That works f=
ine for class templates (and is in fact the approach I took for my paper), =
but not for function templates.&nbsp; I think template meta-parameters do a=
 nice job of increasing flexibility while reducing noise.&nbsp; They also c=
over the typed_value_list scenario above:<br><br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> T </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> ts</span><span sty=
le=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: #0=
08;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> typed_value_list</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span></div></code></div><br></div><=
/div>

<p></p>

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

------=_Part_889_324487607.1420845023579--
------=_Part_888_892259344.1420845023579--

.

------=_Part_921_760027202.1420846160611
Content-Type: multipart/alternative;
 boundary="----=_Part_922_544451658.1420846160611"

------=_Part_922_544451658.1420846160611
Content-Type: text/plain; charset=UTF-8



On Saturday, January 10, 2015 at 12:10:23 AM UTC+1, bek...@gmail.com wrote:
>
> On Friday, January 9, 2015 at 3:00:56 PM UTC-8, inkwizyt...@gmail.com
> wrote:
>>
>> Do you consider using `using` as keyword?
>> some thing like that:
>> template<using All, using... AllMultiple>
>>
>
> It's a possibility; I wanted to avoid overloading using  in this way
> because I think it doesn't read as nicely, but that's a bikeshedding
> conversation; I'm more concerned that the syntax allows for all of the
> stated functionality (and either choice does).
>

`using` is my favorite bikeshed :)



>
>> *Template meta-parameters:* template using typename Fn, typename T <Fn
>>> fn, T... t> ...
>>>
>> I don't think its is require. `auto` and specialization could do this too:
>> template<auto X> struct func = delete; //only used as proxy
>> template<typename R, typename... Args> struct func<R (* f)(Args...)>
>> struct func { };
>>
>>
> That works fine for class templates (and is in fact the approach I took
> for my paper), but not for function templates.  I think template
> meta-parameters do a nice job of increasing flexibility while reducing
> noise.  They also cover the typed_value_list scenario above:
>
> template using typename T <T... ts> struct typed_value_list;
>
>
This is right, without any helper class and boilerplate its hard archive it
with only `auto`.
But this is worth completely new syntax? I personaly dislike that syntax,
it don't have "C++ feel" for me. I would prefer original ones.

--

---
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_922_544451658.1420846160611
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 10, 2015 at 12:10:23 AM UTC+1=
, bek...@gmail.com wrote:<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">On Friday, January 9, 2015 at 3:00:56 PM UTC-8, <a>inkwizyt...@=
gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Do you consider using `using` as keyword?<br><div>some thing like that:<b=
r><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</s=
pan><span style=3D"color:#008">using</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#606">All</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">using</span><=
span style=3D"color:#660">...</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">AllMultiple</span><span style=3D"color:#660">&gt;</s=
pan></div></code></div></div></div></blockquote><div><br>It's a possibility=
; I wanted to avoid overloading <span style=3D"font-family:courier new,mono=
space">using</span>&nbsp; in this way because I think it doesn't read as ni=
cely, but that's a bikeshedding conversation; I'm more concerned that the s=
yntax allows for all of the stated functionality (and either choice does).<=
/div></div></blockquote><div><br>`using` is my favorite bikeshed :)<br><br>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><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><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div><b>Template
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ... <br></=
div></blockquote><div>I don't think its is require. `auto` and specializati=
on could do this too:<br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:#008">template</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#000"> X</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> func </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">delete</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D=
"color:#800">//only used as proxy</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#008">template</span><span style=3D"color:#660">&lt=
;</span><span style=3D"color:#008">typename</span><span style=3D"color:#000=
"> R</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">typename</span><span style=3D"color:#660">=
....</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Arg=
s</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">struct</span><span style=3D"color:#000"> f=
unc</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">=
R </span><span style=3D"color:#660">(*</span><span style=3D"color:#000"> f<=
/span><span style=3D"color:#660">)(</span><span style=3D"color:#606">Args</=
span><span style=3D"color:#660">...)&gt;</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">struct</span><span style=3D"color:#000"> =
func </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><=
/span></div></code></div><br></div></div></blockquote><div><br>That works f=
ine for class templates (and is in fact the approach I took for my paper), =
but not for function templates.&nbsp; I think template meta-parameters do a=
 nice job of increasing flexibility while reducing noise.&nbsp; They also c=
over the typed_value_list scenario above:<br><br><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">te=
mplate</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
using</span><span style=3D"color:#000"> </span><span style=3D"color:#008">t=
ypename</span><span style=3D"color:#000"> T </span><span style=3D"color:#66=
0">&lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660"=
>...</span><span style=3D"color:#000"> ts</span><span style=3D"color:#660">=
&gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#008">st=
ruct</span><span style=3D"color:#000"> typed_value_list</span><span style=
=3D"color:#660">;</span></div></code></div><br></div></div></blockquote><di=
v>&nbsp;<br>This is right, without any helper class and boilerplate its har=
d archive it with only `auto`.<br>But this is worth completely new syntax? =
I personaly dislike that syntax, it don't have "C++ feel" for me. I would p=
refer original ones.<br></div></div>

<p></p>

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

------=_Part_922_544451658.1420846160611--
------=_Part_921_760027202.1420846160611--

.

------=_Part_1576_2072065316.1420846273314
Content-Type: multipart/alternative;
 boundary="----=_Part_1577_1606946260.1420846273314"

------=_Part_1577_1606946260.1420846273314
Content-Type: text/plain; charset=UTF-8

I really like the idea of having "auto" for template parameters. However,
be aware of the following trap that most users will fall in when we get
concept-lite.

template <auto X> class C; // X is non-type

But I want something more constrained than 'auto'. So I do this :
template <Constrained X> class C; // Oops! X is now a type!

So you can see the inconcistency... but in my opinion concepts-lite are at
fault (not your proposal).


On Friday, January 9, 2015 at 5:46:23 PM UTC-5, bek...@gmail.com wrote:

> OK, I think we have a pretty good idea of desired features at this point:
>
>    - "AnyType" template value parameters (my original motivation)
>    - "AnythingAtAll" template parameters
>    - Template meta-parameters (what N3601 refers to as "implicit template
>    parameters", but I really think it's more a way of templatizing a template)
>
> I think all of these can peacefully coexist in the same standard.  Here's
> my idea (I'll update the paper when I find some time):
>
> *"AnyType" template value parameters:* template <auto x, auto... y> ...
> Keep my proposed syntax.  I understand the desire to use auto to mean
> "anything at all," but I think we need a keyword that specifically
> introduces a value parameter, and auto is the only existing keyword that
> fits the bill.  I would prefer something like var (in place of *all*
> existing uses of auto), but that ship has long-since sailed.
> *"AnythingAtAll" template parameters:* template <T, x, Templ, ...
> Whatever> ...
> Anything parameters simply have no introducing keyword.  In this model, an
> introducing keyword (typename, class, template, auto) serves to
> explicitly limit the classification of the template parameter; the
> *absence* of such a keyword means that the classification is determined
> at the point of instantiation.  (The ellipsis inside the angle brackets
> introduces a parameter pack of AnythingAtAlls.)
> *Template meta-parameters:* template using typename Fn, typename T <Fn
> fn, T... t> ...
> This is the same as N3601, except that I've moved the using keyword
> outside the parameter list to emphasize that Fn and T are not template
> parameters.  This keeps a 1:1 correlation between the elements of a
> template parameter list and elements of argument lists at points of
> instantiation.  That is, given a declaration:
> template using typename R, typename... Args <R (* f)(Args...)> struct func;
> ...the point of use looks like:
> func<MyFunc> myfunc;
> ...and in both cases there's only one item in the angle brackets.
>
> In terms of functionality, this seems to cover all the bases.
>

--

---
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_1577_1606946260.1420846273314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I really like the idea of having "auto" for template =
parameters. However, be aware of the following trap that most users will fa=
ll in when we get concept-lite.</div><div>&nbsp;</div><div><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); -ms-word-wrap: br=
eak-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 136);">template</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(102, 102, 0);">&lt;</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 136);">auto</span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);"> X</span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(102, 102, 0);">&gt;</span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 136);">class</span><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(0, 0, 0);"> C</span><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(136, 0, 0);">// X is non-type</=
span></div></code></div></div><div>&nbsp;</div><div>But I want something mo=
re constrained than 'auto'. So I do this :</div><div class=3D"prettyprint" =
style=3D"border: 1px solid rgb(187, 187, 187); -ms-word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: rgb=
(0, 0, 136);">template</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0);">&lt;</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 0, 102);">Constrained</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0);"> X</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(102, 102, 0);">&gt;</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(0, 0, 136);">class</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"> C</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D=
"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(136, 0, 0);">// Oops! X is now a ty=
pe!</span></div></code></div><div>&nbsp;</div><div>So you can see the incon=
cistency... but in my opinion concepts-lite are at fault (not your proposal=
).<br></div><div>&nbsp;</div><div><br>On Friday, January 9, 2015 at 5:46:23=
 PM UTC-5, bek...@gmail.com wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr">OK, I think we have a pretty good idea of desired features at th=
is point:<br><ul><li>"AnyType" template value parameters (my original motiv=
ation)<br></li><li>"AnythingAtAll" template parameters</li><li>Template
 meta-parameters (what N3601 refers to as "implicit template=20
parameters", but I really think it's more a way of templatizing a=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.&nbsp; Here's my idea (I'll update the paper when I find some time=
):<br><br><b>"AnyType" template value parameters:</b> <span style=3D"font-f=
amily: courier new,monospace;">template &lt;auto x, auto... y&gt;</span> ..=
..<br><div style=3D"margin-left: 40px;">Keep my proposed syntax.&nbsp; I und=
erstand the desire to use <span style=3D"font-family: courier new,monospace=
;">auto</span>
 to mean "anything at all," but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family: =
courier new,monospace;">auto</span> is the only existing
 keyword that fits the bill.&nbsp; I would prefer something like <span styl=
e=3D"font-family: courier new,monospace;">var</span> (in place of <i>all</i=
> existing uses of <span style=3D"font-family: courier new,monospace;">auto=
</span>), but that ship has long-since sailed.<br></div><b>"AnythingAtAll" =
template parameters:</b> <span style=3D"font-family: courier new,monospace;=
">template &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=3D"ma=
rgin-left: 40px;">Anything parameters simply have no introducing keyword.&n=
bsp; In this model, an introducing keyword (<span style=3D"font-family: cou=
rier new,monospace;">typename</span>, <span style=3D"font-family: courier n=
ew,monospace;">class</span>, <span style=3D"font-family: courier new,monosp=
ace;">template</span>, <span style=3D"font-family: courier new,monospace;">=
auto</span>) serves to explicitly limit the classification of the template =
parameter; the <i>absence</i> of such a keyword means that the classificati=
on is determined at the point of instantiation.&nbsp; (The ellipsis inside =
the angle brackets introduces a parameter pack of AnythingAtAlls.)<br></div=
><b>Template
 meta-parameters:</b> <span style=3D"font-family: courier new,monospace;">t=
emplate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><=
div style=3D"margin-left: 40px;">This is the same as N3601, except that I'v=
e moved the <span style=3D"font-family: courier new,monospace;">using</span=
> keyword outside the parameter list to emphasize that <span style=3D"font-=
family: courier new,monospace;">Fn</span> and <span style=3D"font-family: c=
ourier new,monospace;">T</span> are not template parameters.&nbsp; This kee=
ps a 1:1 correlation between the elements of a template parameter list and =
elements of argument lists at points of instantiation.&nbsp; That is, given=
 a declaration:<br><div style=3D"margin-left: 40px;"><span style=3D"font-fa=
mily: courier new,monospace;">template using typename R, typename... Args &=
lt;R (* f)(Args...)&gt; struct func;</span><br></div>...the point of use lo=
oks like:<br><div style=3D"margin-left: 40px;"><span style=3D"font-family: =
courier new,monospace;">func&lt;MyFunc&gt; myfunc;</span><br></div>...and i=
n both cases there's only one item in the angle brackets.<br></div><br>In t=
erms of functionality, this seems to cover all the bases.<br></div></blockq=
uote></div>

<p></p>

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

------=_Part_1577_1606946260.1420846273314--
------=_Part_1576_2072065316.1420846273314--

.

------=_Part_1254_2110600182.1420846696180
Content-Type: multipart/alternative;
 boundary="----=_Part_1255_722377728.1420846696180"

------=_Part_1255_722377728.1420846696180
Content-Type: text/plain; charset=UTF-8



On Saturday, January 10, 2015 at 12:31:13 AM UTC+1, Alex B wrote:
>
> I really like the idea of having "auto" for template parameters. However,
> be aware of the following trap that most users will fall in when we get
> concept-lite.
>
> template <auto X> class C; // X is non-type
>
> But I want something more constrained than 'auto'. So I do this :
> template <Constrained X> class C; // Oops! X is now a type!
>
> So you can see the inconcistency... but in my opinion concepts-lite are at
> fault (not your proposal).
>
>

I think concepts are more inconsistent :) consider:
template<Number I> func(Number b); //different meaning, I is type, b is
value
template<auto I> func(auto b); //same meaning, I is value, b is value
int main()
{
    Number a = 1000; //like auto, a is value
    auto b = 12;
}


--

---
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_1255_722377728.1420846696180
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, January 10, 2015 at 12:31:13 AM UTC+1=
, Alex B wrote:<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>I really like the idea of having "auto" for template parameters. How=
ever, be aware of the following trap that most users will fall in when we g=
et concept-lite.</div><div>&nbsp;</div><div><div style=3D"border:1px solid =
rgb(187,187,187);background-color:rgb(250,250,250)"><code><div><span style=
=3D"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(0,0,0)"> </=
span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:r=
gb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> X</span><span sty=
le=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> </=
span><span style=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rg=
b(0,0,0)"> C</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// X is no=
n-type</span></div></code></div></div><div>&nbsp;</div><div>But I want some=
thing more constrained than 'auto'. So I do this :</div><div style=3D"borde=
r:1px solid rgb(187,187,187);background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=
=3D"color:rgb(102,0,102)">Constrained</span><span style=3D"color:rgb(0,0,0)=
"> X</span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><sp=
an style=3D"color:rgb(0,0,0)"> C</span><span style=3D"color:rgb(102,102,0)"=
>;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(=
136,0,0)">// Oops! X is now a type!</span></div></code></div><div>&nbsp;</d=
iv><div>So you can see the inconcistency... but in my opinion concepts-lite=
 are at fault (not your proposal).<br></div><div>&nbsp;</div></div></blockq=
uote><div>&nbsp;</div><div>I think concepts are more inconsistent :) consid=
er:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Number</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> I</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Number</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//different meaning, I is type, b is value</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><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">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> I</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">//same meaning, I is value, b is value</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Number</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1000</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//like auto, a is value=
</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">au=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">12</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=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-b=
y-prettify"><br></span></div></code></div><br><br></div></div>

<p></p>

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

------=_Part_1255_722377728.1420846696180--
------=_Part_1254_2110600182.1420846696180--

.

On Fri, Jan 9, 2015 at 3:10 PM,  <bekenn@gmail.com> wrote:
> On Friday, January 9, 2015 at 3:00:56 PM UTC-8, inkwizyt...@gmail.com wro=
te:
>>
>>> Template meta-parameters: template using typename Fn, typename T <Fn fn=
,
>>> T... t> ...
>>
>> I don't think its is require. `auto` and specialization could do this to=
o:
>> template<auto X> struct func =3D delete; //only used as proxy
>> template<typename R, typename... Args> struct func<R (* f)(Args...)>
>> struct func { };
>
> That works fine for class templates (and is in fact the approach I took f=
or
> my paper), but not for function templates.  I think template meta-paramet=
ers
> do a nice job of increasing flexibility while reducing noise.  They also
> cover the typed_value_list scenario above:
>
> template using typename T <T... ts> struct typed_value_list;

Nitpick: the proposed N3601 syntax is
    template<using typename T, T... ts> struct typed_value_list;
isn't it?

Also, when you say it "doesn't work for function templates," that's
only because function templates in C++14 don't have partial
specialization, right?  I've heard rumors that partial specialization
for function and variable templates might be coming in C++17, because
there's no problem with implementing them; it's just a matter of
someone making the proposal.

Finally, on Bekann's proposal of

    template<T> class anything { ... };

where the *lack* of introductory keyword means "do the right thing": I
doubt that should fly, even aside from the killer ambiguity inkwizyt
pointed out, because it was "lack of introductory keyword" that ended
up killing the

    for (elt : container)

syntax (Stephan T. Lavavej's N3994). In other words, not only is there
no precedent for "identifier with no introductory keyword" in C++14,
there now *is* precedent for such proposals to be rejected on that
ground alone.  I'm not saying it's fair or right; I'm just saying it's
a precedent.

=E2=80=93Arthur

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

.

------=_Part_863_800882248.1420851264715
Content-Type: multipart/alternative;
 boundary="----=_Part_864_442740.1420851264715"

------=_Part_864_442740.1420851264715
Content-Type: text/plain; charset=UTF-8

On Friday, January 9, 2015 at 4:42:27 PM UTC-8, Arthur O'Dwyer wrote:
>
> > template using typename T <T... ts> struct typed_value_list;
>
> Nitpick: the proposed N3601 syntax is
>     template<using typename T, T... ts> struct typed_value_list;
> isn't it?
>
>
That's intentional; I pointed this out myself a few posts ago.  The intent
is to make meta-parameters not look like template parameters.


> Also, when you say it "doesn't work for function templates," that's
> only because function templates in C++14 don't have partial
> specialization, right?


Correct, although I see no reason both features can't coexist.  I think in
many cases, template meta-parameters can remove the need for
specializations, which I see as a good thing.


> Finally, on Bek*e*nn's proposal of
>
>     template<T> class anything { ... };
>
> where the *lack* of introductory keyword means "do the right thing": I
> doubt that should fly, even aside from the killer ambiguity inkwizyt
> pointed out, because it was "lack of introductory keyword" that ended
> up killing the
>
>     for (elt : container)
>
> syntax (Stephan T. Lavavej's N3994). In other words, not only is there
> no precedent for "identifier with no introductory keyword" in C++14,
> there now *is* precedent for such proposals to be rejected on that
> ground alone.  I'm not saying it's fair or right; I'm just saying it's
> a precedent.
>
>
You're right; I think using has a better chance here than nothing, although
aesthetically my preference is still nothing.

--

---
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_864_442740.1420851264715
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, January 9, 2015 at 4:42:27 PM UTC-8, Arthur O'D=
wyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; template using=
 typename T &lt;T... ts&gt; struct typed_value_list;
<br>
<br>Nitpick: the proposed N3601 syntax is
<br>&nbsp; &nbsp; template&lt;using typename T, T... ts&gt; struct typed_va=
lue_list;
<br>isn't it?
<br>
<br></blockquote><div><br>That's intentional; I pointed this out myself a f=
ew posts ago.&nbsp; The intent is to make meta-parameters not look like tem=
plate parameters.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">Also, when you say it "doesn't work for function templates," that's
<br>only because function templates in C++14 don't have partial
<br>specialization, right? &nbsp;</blockquote><div><br>Correct, although I =
see no reason both features can't coexist.&nbsp; I think in many cases, tem=
plate meta-parameters can remove the need for specializations, which I see =
as a good thing.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<br>Finally, on Bek<span style=3D"color: rgb(255, 0, 0);"><b>e</b></span>nn=
's proposal of
<br>
<br>&nbsp; &nbsp; template&lt;T&gt; class anything { ... };
<br>
<br>where the *lack* of introductory keyword means "do the right thing": I
<br>doubt that should fly, even aside from the killer ambiguity inkwizyt
<br>pointed out, because it was "lack of introductory keyword" that ended
<br>up killing the
<br>
<br>&nbsp; &nbsp; for (elt : container)
<br>
<br>syntax (Stephan T. Lavavej's N3994). In other words, not only is there
<br>no precedent for "identifier with no introductory keyword" in C++14,
<br>there now *is* precedent for such proposals to be rejected on that
<br>ground alone. &nbsp;I'm not saying it's fair or right; I'm just saying =
it's
<br>a precedent.
<br>
<br></blockquote><div><br>You're right; I think <span style=3D"font-family:=
 courier new,monospace;">using</span> has a better chance here than nothing=
, although aesthetically my preference is still nothing.<br><br></div></div=
>

<p></p>

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

------=_Part_864_442740.1420851264715--
------=_Part_863_800882248.1420851264715--

.

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

2015-01-10 2:16 GMT+03:30 <bekenn@gmail.com>:

> *Template meta-parameters:* template using typename Fn, typename T <Fn
> fn, T... t> ...
> This is the same as N3601, except that I've moved the using keyword
> outside the parameter list to emphasize that Fn and T are not template
> parameters.  This keeps a 1:1 correlation between the elements of a
> template parameter list and elements of argument lists at points of
> instantiation.  That is, given a declaration:
> template using typename R, typename... Args <R (* f)(Args...)> struct func;
> ...the point of use looks like:
> func<MyFunc> myfunc;
> ...and in both cases there's only one item in the angle brackets.
>
> In terms of functionality, this seems to cover all the bases.
>

why should we stick to keywords; aren`t they already extensively
overloaded? In my earlier post a keyword free syntax has been demonstrated
for the purpose.

regards,
FM.

--

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

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

<div dir=3D"rtl"><div class=3D"gmail_extra"><div dir=3D"ltr"><br><div class=
=3D"gmail_quote">2015-01-10 2:16 GMT+03:30  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bekenn@gmail.com" target=3D"_blank">bekenn@gmail.com</a>&gt;</sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><b>Template
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><di=
v style=3D"margin-left:40px">This is the same as N3601, except that I&#39;v=
e moved the <span style=3D"font-family:courier new,monospace">using</span> =
keyword outside the parameter list to emphasize that <span style=3D"font-fa=
mily:courier new,monospace">Fn</span> and <span style=3D"font-family:courie=
r new,monospace">T</span> are not template parameters.=C2=A0 This keeps a 1=
:1 correlation between the elements of a template parameter list and elemen=
ts of argument lists at points of instantiation.=C2=A0 That is, given a dec=
laration:<br><div style=3D"margin-left:40px"><span style=3D"font-family:cou=
rier new,monospace">template using typename R, typename... Args &lt;R (* f)=
(Args...)&gt; struct func;</span><br></div>...the point of use looks like:<=
br><div style=3D"margin-left:40px"><span style=3D"font-family:courier new,m=
onospace">func&lt;MyFunc&gt; myfunc;</span><br></div>...and in both cases t=
here&#39;s only one item in the angle brackets.<br></div><br>In terms of fu=
nctionality, this seems to cover all the bases.<br></blockquote><div><br></=
div><div>why should we stick to keywords; aren`t they already extensively o=
verloaded? In my earlier post a keyword free syntax has been demonstrated f=
or the purpose.</div><div><br></div><div>regards,</div><div>FM.</div></div>=
</div>
</div></div>

<p></p>

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

--bcaec53f382311a470050c63ac81--

.

--Apple-Mail=_26322262-1A4F-4994-94B9-18540B17C4F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


Il giorno 09/gen/2015, alle ore 23:46, bekenn@gmail.com ha scritto:

> OK, I think we have a pretty good idea of desired features at this point:
> "AnyType" template value parameters (my original motivation)
> "AnythingAtAll" template parameters
> Template meta-parameters (what N3601 refers to as "implicit template para=
meters", but I really think it's more a way of templatizing a template)
> I think all of these can peacefully coexist in the same standard.  Here's=
 my idea (I'll update the paper when I find some time):
>=20
> "AnyType" template value parameters: template <auto x, auto... y> ...
> Keep my proposed syntax.  I understand the desire to use auto to mean "an=
ything at all," but I think we need a keyword that specifically introduces =
a value parameter, and auto is the only existing keyword that fits the bill=
..  I would prefer something like var (in place of all existing uses of auto=
), but that ship has long-since sailed.
> "AnythingAtAll" template parameters: template <T, x, Templ, ... Whatever>=
 ...
> Anything parameters simply have no introducing keyword.  In this model, a=
n introducing keyword (typename, class, template, auto) serves to explicitl=
y limit the classification of the template parameter; the absence of such a=
 keyword means that the classification is determined at the point of instan=
tiation.  (The ellipsis inside the angle brackets introduces a parameter pa=
ck of AnythingAtAlls.)
> Template meta-parameters: template using typename Fn, typename T <Fn fn, =
T... t> ...
> This is the same as N3601, except that I've moved the using keyword outsi=
de the parameter list to emphasize that Fn and T are not template parameter=
s.  This keeps a 1:1 correlation between the elements of a template paramet=
er list and elements of argument lists at points of instantiation.  That is=
, given a declaration:
> template using typename R, typename... Args <R (* f)(Args...)> struct fun=
c;
> ...the point of use looks like:
> func<MyFunc> myfunc;
> ...and in both cases there's only one item in the angle brackets.
>=20
> In terms of functionality, this seems to cover all the bases.
>=20

FWIW, I really like this idea.=20
Like others, I think the absence of keywords in the AnythingAtAll case coul=
d=20
create problems to some people, even though I like it.

I don=E2=80=99t particularly like =E2=80=98using=E2=80=99 in this context. =
It doesn=E2=80=99t make sense when=20
spelling the code.

What about a new keyword at all?=20

Bye,
Nicola

P.S. or, since we have =E2=80=98auto=E2=80=99, why not =E2=80=98register'? =
LoL

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

--Apple-Mail=_26322262-1A4F-4994-94B9-18540B17C4F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>Il giorn=
o 09/gen/2015, alle ore 23:46, <a href=3D"mailto:bekenn@gmail.com">bekenn@g=
mail.com</a> ha scritto:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div dir=3D"ltr">OK, I think we have a pretty good ide=
a of desired features at this point:<br><ul><li>"AnyType" template value pa=
rameters (my original motivation)<br></li><li>"AnythingAtAll" template para=
meters</li><li>Template
 meta-parameters (what N3601 refers to as "implicit template=20
parameters", but I really think it's more a way of templatizing a=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.&nbsp; Here's my idea (I'll update the paper when I find some time=
):<br><br><b>"AnyType" template value parameters:</b> <span style=3D"font-f=
amily: courier new,monospace;">template &lt;auto x, auto... y&gt;</span> ..=
..<br><div style=3D"margin-left: 40px;">Keep my proposed syntax.&nbsp; I und=
erstand the desire to use <span style=3D"font-family: courier new,monospace=
;">auto</span>
 to mean "anything at all," but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family: =
courier new,monospace;">auto</span> is the only existing
 keyword that fits the bill.&nbsp; I would prefer something like <span styl=
e=3D"font-family: courier new,monospace;">var</span> (in place of <i>all</i=
> existing uses of <span style=3D"font-family: courier new,monospace;">auto=
</span>), but that ship has long-since sailed.<br></div><b>"AnythingAtAll" =
template parameters:</b> <span style=3D"font-family: courier new,monospace;=
">template &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=3D"ma=
rgin-left: 40px;">Anything parameters simply have no introducing keyword.&n=
bsp; In this model, an introducing keyword (<span style=3D"font-family: cou=
rier new,monospace;">typename</span>, <span style=3D"font-family: courier n=
ew,monospace;">class</span>, <span style=3D"font-family: courier new,monosp=
ace;">template</span>, <span style=3D"font-family: courier new,monospace;">=
auto</span>) serves to explicitly limit the classification of the template =
parameter; the <i>absence</i> of such a keyword means that the classificati=
on is determined at the point of instantiation.&nbsp; (The ellipsis inside =
the angle brackets introduces a parameter pack of AnythingAtAlls.)<br></div=
><b>Template
 meta-parameters:</b> <span style=3D"font-family: courier new,monospace;">t=
emplate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><=
div style=3D"margin-left: 40px;">This is the same as N3601, except that I'v=
e moved the <span style=3D"font-family: courier new,monospace;">using</span=
> keyword outside the parameter list to emphasize that <span style=3D"font-=
family: courier new,monospace;">Fn</span> and <span style=3D"font-family: c=
ourier new,monospace;">T</span> are not template parameters.&nbsp; This kee=
ps a 1:1 correlation between the elements of a template parameter list and =
elements of argument lists at points of instantiation.&nbsp; That is, given=
 a declaration:<br><div style=3D"margin-left: 40px;"><span style=3D"font-fa=
mily: courier new,monospace;">template using typename R, typename... Args &=
lt;R (* f)(Args...)&gt; struct func;</span><br></div>...the point of use lo=
oks like:<br><div style=3D"margin-left: 40px;"><span style=3D"font-family: =
courier new,monospace;">func&lt;MyFunc&gt; myfunc;</span><br></div>...and i=
n both cases there's only one item in the angle brackets.<br></div><br>In t=
erms of functionality, this seems to cover all the bases.<br></div><div><br=
 class=3D"webkit-block-placeholder"></div></blockquote><div><br></div><div>=
FWIW, I really like this idea.&nbsp;</div><div>Like others, I think the abs=
ence of keywords in the AnythingAtAll case could&nbsp;</div><div>create pro=
blems to some people, even though I like it.</div><div><br></div><div>I don=
=E2=80=99t particularly like =E2=80=98using=E2=80=99 in this context. It do=
esn=E2=80=99t make sense when&nbsp;</div><div>spelling the code.</div><div>=
<br></div><div>What about a new keyword at all?&nbsp;</div><div><br></div><=
div>Bye,</div><div>Nicola</div><div><br></div><div>P.S. or, since we have =
=E2=80=98auto=E2=80=99, why not =E2=80=98register'? LoL</div></div></body><=
/html>

<p></p>

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

--Apple-Mail=_26322262-1A4F-4994-94B9-18540B17C4F6--

.

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

On Fri, Jan 9, 2015 at 3:31 PM, Alex B <devalexb@gmail.com> wrote:

> I really like the idea of having "auto" for template parameters. However,
> be aware of the following trap that most users will fall in when we get
> concept-lite.
>
> template <auto X> class C; // X is non-type
>
> But I want something more constrained than 'auto'. So I do this :
> template <Constrained X> class C; // Oops! X is now a type!
>

X is the same kind as the prototype parameter of Constrained. If you have:

  template<auto X> concept bool Constrained = f(X) == 3;

.... then

  template<Constrained X> class C;

would give you a class with a non-type template parameter X with the
relevant constraint applied.

If Constrained were a type template, you'd need to write:

template<auto X>
  requires Constrained<decltype(X)>
class C;

I'm not sure how surprising people will find that, but it seems fairly
natural to me.

So you can see the inconcistency... but in my opinion concepts-lite are at
> fault (not your proposal).
>

There is a "sort-of" inconsistency here: if C is a type constraint:

  template<typename T> concept bool C = true;

then "C x" sometimes declares x to be a type, and sometimes declares x to
be a non-type, whereas "auto x" always declares x to be a non-type:

  template<C a, auto b> // a is a type, b is a non-type
  void f(C c, auto d) { // c and d are both non-types
    [](C e, auto f) {}; // e and f are both non-types
  }

But I don't think this is particularly surprising; there's a surface
similarity between 'auto' and a concept-name, and they both act as
placeholders, but they're fundamentally different things. Another example
of them differing:

  void f(C a, C b); // 'a' and 'b' must deduce to the same type
  void f(auto a, auto b); // 'a' and 'b' can deduce to different types

On Friday, January 9, 2015 at 5:46:23 PM UTC-5, bek...@gmail.com wrote:
>
>> OK, I think we have a pretty good idea of desired features at this point:
>>
>>    - "AnyType" template value parameters (my original motivation)
>>    - "AnythingAtAll" template parameters
>>    - Template meta-parameters (what N3601 refers to as "implicit
>>    template parameters", but I really think it's more a way of templatizing a
>>    template)
>>
>> I think all of these can peacefully coexist in the same standard.  Here's
>> my idea (I'll update the paper when I find some time):
>>
>> *"AnyType" template value parameters:* template <auto x, auto... y> ...
>> Keep my proposed syntax.  I understand the desire to use auto to mean
>> "anything at all," but I think we need a keyword that specifically
>> introduces a value parameter, and auto is the only existing keyword that
>> fits the bill.  I would prefer something like var (in place of *all*
>> existing uses of auto), but that ship has long-since sailed.
>> *"AnythingAtAll" template parameters:* template <T, x, Templ, ...
>> Whatever> ...
>> Anything parameters simply have no introducing keyword.  In this model,
>> an introducing keyword (typename, class, template, auto) serves to
>> explicitly limit the classification of the template parameter; the
>> *absence* of such a keyword means that the classification is determined
>> at the point of instantiation.  (The ellipsis inside the angle brackets
>> introduces a parameter pack of AnythingAtAlls.)
>> *Template meta-parameters:* template using typename Fn, typename T <Fn
>> fn, T... t> ...
>> This is the same as N3601, except that I've moved the using keyword
>> outside the parameter list to emphasize that Fn and T are not template
>> parameters.  This keeps a 1:1 correlation between the elements of a
>> template parameter list and elements of argument lists at points of
>> instantiation.  That is, given a declaration:
>> template using typename R, typename... Args <R (* f)(Args...)> struct
>> func;
>> ...the point of use looks like:
>> func<MyFunc> myfunc;
>> ...and in both cases there's only one item in the angle brackets.
>>
>> In terms of functionality, this seems to cover all the bases.
>>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 9, 2015 at 3:31 PM, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:=
devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wro=
te:<br><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>I really like t=
he idea of having &quot;auto&quot; for template parameters. However, be awa=
re of the following trap that most users will fall in when we get concept-l=
ite.</div><div>=C2=A0</div><div><div style=3D"border:1px solid rgb(187,187,=
187);background-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb=
(0,0,136)">template</span><span style=3D"color:rgb(0,0,0)"> </span><span st=
yle=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,136)">=
auto</span><span style=3D"color:rgb(0,0,0)"> X</span><span style=3D"color:r=
gb(102,102,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> </span><span st=
yle=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> C<=
/span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb=
(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// X is non-type</span>=
</div></code></div></div><div>=C2=A0</div><div>But I want something more co=
nstrained than &#39;auto&#39;. So I do this :</div><div style=3D"border:1px=
 solid rgb(187,187,187);background-color:rgb(250,250,250)"><code><div><span=
 style=3D"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"c=
olor:rgb(102,0,102)">Constrained</span><span style=3D"color:rgb(0,0,0)"> X<=
/span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><span st=
yle=3D"color:rgb(0,0,0)"> C</span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(136,0=
,0)">// Oops! X is now a type!</span></div></code></div></div></blockquote>=
<div><br></div><div>X is the same kind as the prototype parameter of Constr=
ained. If you have:</div><div><br></div><div>=C2=A0 template&lt;auto X&gt; =
concept bool Constrained =3D f(X) =3D=3D 3;</div><div><br></div><div>... th=
en</div><div><br></div><div>=C2=A0 template&lt;Constrained X&gt; class C;</=
div><div><br></div><div>would give you a class with a non-type template par=
ameter X with the relevant constraint applied.</div><div><br></div><div>If =
Constrained were a type template, you&#39;d need to write:</div><div><br></=
div><div>template&lt;auto X&gt;</div><div>=C2=A0 requires Constrained&lt;de=
cltype(X)&gt;</div><div>class C;</div><div><br></div><div>I&#39;m not sure =
how surprising people will find that, but it seems fairly natural to me.</d=
iv><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></di=
v><div>So you can see the inconcistency... but in my opinion concepts-lite =
are at fault (not your proposal).</div></div></blockquote><div><br></div><d=
iv>There is a &quot;sort-of&quot; inconsistency here: if C is a type constr=
aint:</div><div><br></div><div>=C2=A0 template&lt;typename T&gt; concept bo=
ol C =3D true;</div><div><br></div><div>then &quot;C x&quot; sometimes decl=
ares x to be a type, and sometimes declares x to be a non-type, whereas &qu=
ot;auto x&quot; always declares x to be a non-type:</div><div><br></div><di=
v>=C2=A0 template&lt;C a, auto b&gt; // a is a type, b is a non-type</div><=
div>=C2=A0 void f(C c, auto d) { // c and d are both non-types</div><div>=
=C2=A0 =C2=A0 [](C e, auto f) {}; // e and f are both non-types</div><div>=
=C2=A0 }<br></div><div><br></div><div>But I don&#39;t think this is particu=
larly surprising; there&#39;s a surface similarity between &#39;auto&#39; a=
nd a concept-name, and they both act as placeholders, but they&#39;re funda=
mentally different things. Another example of them differing:</div><div><br=
></div><div>=C2=A0 void f(C a, C b); // &#39;a&#39; and &#39;b&#39; must de=
duce to the same type</div><div>=C2=A0 void f(auto a, auto b); // &#39;a&#3=
9; and &#39;b&#39; can deduce to different types</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"h5"><div></div=
><div>On Friday, January 9, 2015 at 5:46:23 PM UTC-5, <a href=3D"mailto:bek=
....@gmail.com" target=3D"_blank">bek...@gmail.com</a> wrote:</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 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">OK, I think we have a pretty good idea of desired =
features at this point:<br><ul><li>&quot;AnyType&quot; template value param=
eters (my original motivation)<br></li><li>&quot;AnythingAtAll&quot; templa=
te parameters</li><li>Template
 meta-parameters (what N3601 refers to as &quot;implicit template=20
parameters&quot;, but I really think it&#39;s more a way of templatizing a=
=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.=C2=A0 Here&#39;s my idea (I&#39;ll update the paper when I find s=
ome time):<br><br><b>&quot;AnyType&quot; template value parameters:</b> <sp=
an style=3D"font-family:courier new,monospace">template &lt;auto x, auto...=
 y&gt;</span> ...<br><div style=3D"margin-left:40px">Keep my proposed synta=
x.=C2=A0 I understand the desire to use <span style=3D"font-family:courier =
new,monospace">auto</span>
 to mean &quot;anything at all,&quot; but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family:c=
ourier new,monospace">auto</span> is the only existing
 keyword that fits the bill.=C2=A0 I would prefer something like <span styl=
e=3D"font-family:courier new,monospace">var</span> (in place of <i>all</i> =
existing uses of <span style=3D"font-family:courier new,monospace">auto</sp=
an>), but that ship has long-since sailed.<br></div><b>&quot;AnythingAtAll&=
quot; template parameters:</b> <span style=3D"font-family:courier new,monos=
pace">template &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=
=3D"margin-left:40px">Anything parameters simply have no introducing keywor=
d.=C2=A0 In this model, an introducing keyword (<span style=3D"font-family:=
courier new,monospace">typename</span>, <span style=3D"font-family:courier =
new,monospace">class</span>, <span style=3D"font-family:courier new,monospa=
ce">template</span>, <span style=3D"font-family:courier new,monospace">auto=
</span>) serves to explicitly limit the classification of the template para=
meter; the <i>absence</i> of such a keyword means that the classification i=
s determined at the point of instantiation.=C2=A0 (The ellipsis inside the =
angle brackets introduces a parameter pack of AnythingAtAlls.)<br></div><b>=
Template
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><di=
v style=3D"margin-left:40px">This is the same as N3601, except that I&#39;v=
e moved the <span style=3D"font-family:courier new,monospace">using</span> =
keyword outside the parameter list to emphasize that <span style=3D"font-fa=
mily:courier new,monospace">Fn</span> and <span style=3D"font-family:courie=
r new,monospace">T</span> are not template parameters.=C2=A0 This keeps a 1=
:1 correlation between the elements of a template parameter list and elemen=
ts of argument lists at points of instantiation.=C2=A0 That is, given a dec=
laration:<br><div style=3D"margin-left:40px"><span style=3D"font-family:cou=
rier new,monospace">template using typename R, typename... Args &lt;R (* f)=
(Args...)&gt; struct func;</span><br></div>...the point of use looks like:<=
br><div style=3D"margin-left:40px"><span style=3D"font-family:courier new,m=
onospace">func&lt;MyFunc&gt; myfunc;</span><br></div>...and in both cases t=
here&#39;s only one item in the angle brackets.<br></div><br>In terms of fu=
nctionality, this seems to cover all the bases.<br></div></blockquote></div=
></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

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

--089e013a270cf65124050c70321f--

.

--047d7bdc117e408c4f050c705eac
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 9, 2015 at 2:46 PM, <bekenn@gmail.com> wrote:

> OK, I think we have a pretty good idea of desired features at this point:
>
>    - "AnyType" template value parameters (my original motivation)
>    - "AnythingAtAll" template parameters
>    - Template meta-parameters (what N3601 refers to as "implicit template
>    parameters", but I really think it's more a way of templatizing a template)
>
> I think all of these can peacefully coexist in the same standard.  Here's
> my idea (I'll update the paper when I find some time):
>
> *"AnyType" template value parameters:* template <auto x, auto... y> ...
> Keep my proposed syntax.  I understand the desire to use auto to mean
> "anything at all," but I think we need a keyword that specifically
> introduces a value parameter, and auto is the only existing keyword that
> fits the bill.
>

+1. This is also entirely consistent with the behavior of 'auto' in generic
lambdas. I would strongly support in committee a paper that proposed only
this feature (as your original draft does).


> I would prefer something like var (in place of *all* existing uses of auto),
> but that ship has long-since sailed.
> *"AnythingAtAll" template parameters:* template <T, x, Templ, ...
> Whatever> ...
> Anything parameters simply have no introducing keyword.  In this model, an
> introducing keyword (typename, class, template, auto) serves to
> explicitly limit the classification of the template parameter; the
> *absence* of such a keyword means that the classification is determined
> at the point of instantiation.  (The ellipsis inside the angle brackets
> introduces a parameter pack of AnythingAtAlls.)
>

This idea seems good, but the syntax probably needs more work. In
particular:

// my code
typedef int foo;

namespace some_library_somewhere {
  template<foo> void f();
}

Does some_library_somewhere::f have an AnythingAtAll template parameter or
a non-type template parameter of type foo (aka int)? This
action-at-a-distance seems troubling; the committee rejected the suggestion
of leaving out the 'auto' in a generic lambda for this reason ("[] (foo)
{}" could be a generic lambda or a lambda with an unnamed parameter of type
'foo').

The idea of an AnythingAtAll parameter (and of an AnyType parameter) has
been discussed on this list before; there were some alternative syntaxes
proposed on that thread, but none that received strong and widespread
support. As a strawman for your proposal, how about "?",  "*", or "using".

*Template meta-parameters:* template using typename Fn, typename T <Fn fn,
> T... t> ...
> This is the same as N3601, except that I've moved the using keyword
> outside the parameter list to emphasize that Fn and T are not template
> parameters.  This keeps a 1:1 correlation between the elements of a
> template parameter list and elements of argument lists at points of
> instantiation.  That is, given a declaration:
> template using typename R, typename... Args <R (* f)(Args...)> struct func;
> ...the point of use looks like:
> func<MyFunc> myfunc;
> ...and in both cases there's only one item in the angle brackets.
>

I can see this being a convenience in some cases. Is it necessary to enable
any of the other functionality, or is it only a syntactic shorthand? Your
example can presumably be written:

  template<auto (*f)(auto...)> struct func;

.... with a little extra work required to extract the return type and
parameter types from f inside the definition of 'func'.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 9, 2015 at 2:46 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:bekenn=
@gmail.com" target=3D"_blank">bekenn@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">OK, I think we have a pretty g=
ood idea of desired features at this point:<br><ul><li>&quot;AnyType&quot; =
template value parameters (my original motivation)<br></li><li>&quot;Anythi=
ngAtAll&quot; template parameters</li><li>Template
 meta-parameters (what N3601 refers to as &quot;implicit template=20
parameters&quot;, but I really think it&#39;s more a way of templatizing a=
=20
template)</li></ul>I think all of these can peacefully coexist in the same =
standard.=C2=A0 Here&#39;s my idea (I&#39;ll update the paper when I find s=
ome time):<br><br><b>&quot;AnyType&quot; template value parameters:</b> <sp=
an style=3D"font-family:courier new,monospace">template &lt;auto x, auto...=
 y&gt;</span> ...<br><div style=3D"margin-left:40px">Keep my proposed synta=
x.=C2=A0 I understand the desire to use <span style=3D"font-family:courier =
new,monospace">auto</span>
 to mean &quot;anything at all,&quot; but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family:c=
ourier new,monospace">auto</span> is the only existing
 keyword that fits the bill.</div></div></blockquote><div><br></div><div>+1=
.. This is also entirely consistent with the behavior of &#39;auto&#39; in g=
eneric lambdas. I would strongly support in committee a paper that proposed=
 only this feature (as your original draft does).</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"margin-left:40px=
">I would prefer something like <span style=3D"font-family:courier new,mono=
space">var</span> (in place of <i>all</i> existing uses of <span style=3D"f=
ont-family:courier new,monospace">auto</span>), but that ship has long-sinc=
e sailed.<br></div><b>&quot;AnythingAtAll&quot; template parameters:</b> <s=
pan style=3D"font-family:courier new,monospace">template &lt;T, x, Templ, .=
... Whatever&gt;</span> ...<br><div style=3D"margin-left:40px">Anything para=
meters simply have no introducing keyword.=C2=A0 In this model, an introduc=
ing keyword (<span style=3D"font-family:courier new,monospace">typename</sp=
an>, <span style=3D"font-family:courier new,monospace">class</span>, <span =
style=3D"font-family:courier new,monospace">template</span>, <span style=3D=
"font-family:courier new,monospace">auto</span>) serves to explicitly limit=
 the classification of the template parameter; the <i>absence</i> of such a=
 keyword means that the classification is determined at the point of instan=
tiation.=C2=A0 (The ellipsis inside the angle brackets introduces a paramet=
er pack of AnythingAtAlls.)<br></div></div></blockquote><div><br></div><div=
>This idea seems good, but the syntax probably needs more work. In particul=
ar:</div><div><br></div><div>// my code</div><div>typedef int foo;</div><di=
v><br></div><div>namespace some_library_somewhere {</div><div>=C2=A0 templa=
te&lt;foo&gt; void f();</div><div>}</div><div><br></div><div>Does some_libr=
ary_somewhere::f have an AnythingAtAll template parameter or a non-type tem=
plate parameter of type foo (aka int)? This action-at-a-distance seems trou=
bling; the committee rejected the suggestion of leaving out the &#39;auto&#=
39; in a generic lambda for this reason (&quot;[] (foo) {}&quot; could be a=
 generic lambda or a lambda with an unnamed parameter of type &#39;foo&#39;=
).</div><div><br></div><div>The idea of an AnythingAtAll parameter (and of =
an AnyType parameter) has been discussed on this list before; there were so=
me alternative syntaxes proposed on that thread, but none that received str=
ong and widespread support. As a strawman for your proposal, how about &quo=
t;?&quot;, =C2=A0&quot;*&quot;, or &quot;using&quot;.</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 style=3D"margin-left:40=
px"></div><b>Template
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><di=
v style=3D"margin-left:40px">This is the same as N3601, except that I&#39;v=
e moved the <span style=3D"font-family:courier new,monospace">using</span> =
keyword outside the parameter list to emphasize that <span style=3D"font-fa=
mily:courier new,monospace">Fn</span> and <span style=3D"font-family:courie=
r new,monospace">T</span> are not template parameters.=C2=A0 This keeps a 1=
:1 correlation between the elements of a template parameter list and elemen=
ts of argument lists at points of instantiation.=C2=A0 That is, given a dec=
laration:<br><div style=3D"margin-left:40px"><span style=3D"font-family:cou=
rier new,monospace">template using typename R, typename... Args &lt;R (* f)=
(Args...)&gt; struct func;</span><br></div>...the point of use looks like:<=
br><div style=3D"margin-left:40px"><span style=3D"font-family:courier new,m=
onospace">func&lt;MyFunc&gt; myfunc;</span><br></div>...and in both cases t=
here&#39;s only one item in the angle brackets.</div></div></blockquote><di=
v><br></div><div>I can see this being a convenience in some cases. Is it ne=
cessary to enable any of the other functionality, or is it only a syntactic=
 shorthand? Your example can presumably be written:</div><div><br></div><di=
v>=C2=A0 template&lt;auto (*f)(auto...)&gt; struct func;</div><div><br></di=
v><div>... with a little extra work required to extract the return type and=
 parameter types from f inside the definition of &#39;func&#39;.<br></div><=
/div></div></div>

<p></p>

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

--047d7bdc117e408c4f050c705eac--

.

------=_Part_2038_380519598.1421052580028
Content-Type: multipart/alternative;
 boundary="----=_Part_2039_797296697.1421052580028"

------=_Part_2039_797296697.1421052580028
Content-Type: text/plain; charset=UTF-8

On Sunday, January 11, 2015 at 9:25:13 AM UTC-8, Farid Mehrabi wrote:
>
>
> why should we stick to keywords; aren`t they already extensively
> overloaded? In my earlier post a keyword free syntax has been demonstrated
> for the purpose.
>
>
Keywords fit existing language patterns and are an aid to readability.
Ideally, someone who is not familiar with the feature would be able to
figure it out just by reading the declaration.

--

---
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_2039_797296697.1421052580028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, January 11, 2015 at 9:25:13 AM UTC-8, Farid Meh=
rabi wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"><d=
iv><div dir=3D"ltr"><br><div class=3D"gmail_quote">why should we stick to k=
eywords; aren`t they already extensively overloaded? In my earlier post a k=
eyword free syntax has been demonstrated for the purpose.<div><br></div></d=
iv></div></div></div></blockquote><div><br>Keywords fit existing language p=
atterns and are an aid to readability.&nbsp; Ideally, someone who is not fa=
miliar with the feature would be able to figure it out just by reading the =
declaration.<br></div></div>

<p></p>

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

------=_Part_2039_797296697.1421052580028--
------=_Part_2038_380519598.1421052580028--

.

------=_Part_1990_2035191074.1421053308697
Content-Type: multipart/alternative;
 boundary="----=_Part_1991_336851302.1421053308697"

------=_Part_1991_336851302.1421053308697
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, January 11, 2015 at 11:02:44 AM UTC-8, Nicola Gigante wrote:
>
>
> FWIW, I really like this idea.=20
>

Thanks!
=20

> Like others, I think the absence of keywords in the AnythingAtAll case=20
> could=20
> create problems to some people, even though I like it.
>
>
Agreed, I think that syntax won't gain traction; I'm not going to stick to=
=20
it.
=20

> I don=E2=80=99t particularly like =E2=80=98using=E2=80=99 in this context=
.. It doesn=E2=80=99t make sense=20
> when=20
> spelling the code.
>

Also agreed, but I don't see a better existing keyword.  The closest I can=
=20
see is default, which still doesn't really work for me.

What about a new keyword at all?=20
>

I get the impression that introducing a new keyword would dramatically=20
decrease the odds of acceptance by the committee.


> P.S. or, since we have =E2=80=98auto=E2=80=99, why not =E2=80=98register'=
? LoL
>

restrict, anyone?=20

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

------=_Part_1991_336851302.1421053308697
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, January 11, 2015 at 11:02:44 AM UTC-8, Nicola G=
igante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><br><div>FWIW, I really like this idea.&nbsp;</div></div=
></blockquote><div><br>Thanks!<br>&nbsp;<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div>Like othe=
rs, I think the absence of keywords in the AnythingAtAll case could&nbsp;</=
div><div>create problems to some people, even though I like it.</div><div><=
br></div></div></div></blockquote><div><br>Agreed, I think that syntax won'=
t gain traction; I'm not going to stick to it.<br>&nbsp;<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><di=
v><div></div><div>I don=E2=80=99t particularly like =E2=80=98using=E2=80=99=
 in this context. It doesn=E2=80=99t make sense when&nbsp;</div><div>spelli=
ng the code.</div></div></div></blockquote><div><br>Also agreed, but I don'=
t see a better existing keyword.&nbsp; The closest I can see is <span style=
=3D"font-family: courier new,monospace;">default</span>, which still doesn'=
t really work for me.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><div><div>What about a new keywor=
d at all?&nbsp;</div></div></div></blockquote><div><br>I get the impression=
 that introducing a new keyword would dramatically decrease the odds of acc=
eptance by the committee.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div style=3D"word-wrap:break-word"><div><br><div>P.S. or, since w=
e have =E2=80=98auto=E2=80=99, why not =E2=80=98register'? LoL</div></div><=
/div></blockquote><div><br><span style=3D"font-family: courier new,monospac=
e;">restrict</span>, anyone? <br></div></div>

<p></p>

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

------=_Part_1991_336851302.1421053308697--
------=_Part_1990_2035191074.1421053308697--

.

------=_Part_381_948929630.1421055658723
Content-Type: multipart/alternative;
 boundary="----=_Part_382_1446728788.1421055658723"

------=_Part_382_1446728788.1421055658723
Content-Type: text/plain; charset=UTF-8

On Monday, January 12, 2015 at 12:34:02 AM UTC-8, Richard Smith wrote:
>
> On Fri, Jan 9, 2015 at 2:46 PM, <bek...@gmail.com <javascript:>> wrote:
>
>> *"AnyType" template value parameters:* template <auto x, auto... y> ...
>> Keep my proposed syntax.  I understand the desire to use auto to mean
>> "anything at all," but I think we need a keyword that specifically
>> introduces a value parameter, and auto is the only existing keyword that
>> fits the bill.
>>
>
> +1. This is also entirely consistent with the behavior of 'auto' in
> generic lambdas. I would strongly support in committee a paper that
> proposed only this feature (as your original draft does).
>

Thanks


>
>
>> *"AnythingAtAll" template parameters:* template <T, x, Templ, ...
>> Whatever> ...
>> Anything parameters simply have no introducing keyword.  In this model,
>> an introducing keyword (typename, class, template, auto) serves to
>> explicitly limit the classification of the template parameter; the
>> *absence* of such a keyword means that the classification is determined
>> at the point of instantiation.  (The ellipsis inside the angle brackets
>> introduces a parameter pack of AnythingAtAlls.)
>>
>
> This idea seems good, but the syntax probably needs more work. In
> particular:
>
> // my code
> typedef int foo;
>
> namespace some_library_somewhere {
>   template<foo> void f();
> }
>
>
This issue has been pointed out, and I agree that it's a blocker.  The
current best option seems to be the using keyword.

The idea of an AnythingAtAll parameter (and of an AnyType parameter) has
> been discussed on this list before; there were some alternative syntaxes
> proposed on that thread, but none that received strong and widespread
> support. As a strawman for your proposal, how about "?",  "*", or "using".
>
>
Using punctuation is interesting, but I think it fails the readability
test.  (My version: Someone generally familiar with the language but
unfamiliar with the feature should be able to figure it out just by reading
the template declaration.)  As a straw man, I'm leaning towards using, but
I'm by no means married to that syntax.

*Template meta-parameters:* template using typename Fn, typename T <Fn fn,
>> T... t> ...
>> This is the same as N3601, except that I've moved the using keyword
>> outside the parameter list to emphasize that Fn and T are not template
>> parameters.  This keeps a 1:1 correlation between the elements of a
>> template parameter list and elements of argument lists at points of
>> instantiation.  That is, given a declaration:
>> template using typename R, typename... Args <R (* f)(Args...)> struct
>> func;
>> ...the point of use looks like:
>> func<MyFunc> myfunc;
>> ...and in both cases there's only one item in the angle brackets.
>>
>
> I can see this being a convenience in some cases. Is it necessary to
> enable any of the other functionality, or is it only a syntactic shorthand?
> Your example can presumably be written:
>
>   template<auto (*f)(auto...)> struct func;
>
> ... with a little extra work required to extract the return type and
> parameter types from f inside the definition of 'func'.
>

After reading N3601, I actually see auto as a shorthand notation for

template using typename _T <_T x>

Template meta-parameters are more flexible and more expressive, but also
more verbose.  While you are correct that in your example above it is
already possible to extract the return and parameter types using partial
specializations, template meta-parameters mean that you don't have to.
Here's an example where you can't currently use partial specialization to
achieve the same effect:

template using typename R, typename... Args <R (* F)(Args...)>
R function_wrapper(Args... args);

The function_wrapper function template is parameterized on the function it
wraps, and is defined as taking the same number and types of arguments as
the function it is wrapping.  In my paper, I achieved a similar effect by
declaring a function pointer variable template that points to a static
member function of a partially specialized struct.  That's a lot of
indirection, made much more straightforward by the declaration above.  With
template meta-parameters, there's no need for the variable template, the
struct template, or any partial specialization of the struct template.
That's a *lot* more convenient, and much more straightforward to read, to
the point where I'd say it justifies the feature.

All of that said, these three features are orthogonal; do you think it
would be better to propose them separately, or all at once?

--

---
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_382_1446728788.1421055658723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 12, 2015 at 12:34:02 AM UTC-8, Richard =
Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On Fri, Jan 9, 2015 at 2:46 PM,  <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"03-Q_OWgVsAJ" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">bek...@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b>"AnyTyp=
e" template value parameters:</b> <span style=3D"font-family:courier new,mo=
nospace">template &lt;auto x, auto... y&gt;</span> ...<br><div style=3D"mar=
gin-left:40px">Keep my proposed syntax.&nbsp; I understand the desire to us=
e <span style=3D"font-family:courier new,monospace">auto</span>
 to mean "anything at all," but I think we need a keyword that=20
specifically introduces a value parameter, and <span style=3D"font-family:c=
ourier new,monospace">auto</span> is the only existing
 keyword that fits the bill.</div></div></blockquote><div><br></div><div>+1=
.. This is also entirely consistent with the behavior of 'auto' in generic l=
ambdas. I would strongly support in committee a paper that proposed only th=
is feature (as your original draft does).</div><div></div></div></div></div=
></blockquote><div><br>Thanks<br>&nbsp;<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b>"AnythingAtAll=
" template parameters:</b> <span style=3D"font-family:courier new,monospace=
">template &lt;T, x, Templ, ... Whatever&gt;</span> ...<br><div style=3D"ma=
rgin-left:40px">Anything parameters simply have no introducing keyword.&nbs=
p; In this model, an introducing keyword (<span style=3D"font-family:courie=
r new,monospace">typename</span>, <span style=3D"font-family:courier new,mo=
nospace">class</span>, <span style=3D"font-family:courier new,monospace">te=
mplate</span>, <span style=3D"font-family:courier new,monospace">auto</span=
>) serves to explicitly limit the classification of the template parameter;=
 the <i>absence</i> of such a keyword means that the classification is dete=
rmined at the point of instantiation.&nbsp; (The ellipsis inside the angle =
brackets introduces a parameter pack of AnythingAtAlls.)<br></div></div></b=
lockquote><div><br></div><div>This idea seems good, but the syntax probably=
 needs more work. In particular:</div><div><br></div><div>// my code</div><=
div>typedef int foo;</div><div><br></div><div>namespace some_library_somewh=
ere {</div><div>&nbsp; template&lt;foo&gt; void f();</div><div>}</div><div>=
<br></div></div></div></div></blockquote><div><br>This issue has been point=
ed out, and I agree that it's a blocker.&nbsp; The current best option seem=
s to be the <font face=3D"courier new,monospace">using<font face=3D"arial,s=
ans-serif"> keyword.<br><br></font></font></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></d=
iv>The idea of an AnythingAtAll parameter (and of an AnyType parameter) has=
 been discussed on this list before; there were some alternative syntaxes p=
roposed on that thread, but none that received strong and widespread suppor=
t. As a strawman for your proposal, how about "?", &nbsp;"*", or "using".<d=
iv><br></div></div></div></div></blockquote><div><br>Using punctuation is i=
nteresting, but I think it fails the readability test.&nbsp; (My version: S=
omeone generally familiar with the language but unfamiliar with the feature=
 should be able to figure it out just by reading the template declaration.)=
&nbsp; As a straw man, I'm leaning towards <span style=3D"font-family: cour=
ier new,monospace;">using</span>, but I'm by no means married to that synta=
x.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div style=3D"margin-left:40px"></div><b>Template
 meta-parameters:</b> <span style=3D"font-family:courier new,monospace">tem=
plate using typename Fn, typename T &lt;Fn fn, T... t&gt;</span> ...<br><di=
v style=3D"margin-left:40px">This is the same as N3601, except that I've mo=
ved the <span style=3D"font-family:courier new,monospace">using</span> keyw=
ord outside the parameter list to emphasize that <span style=3D"font-family=
:courier new,monospace">Fn</span> and <span style=3D"font-family:courier ne=
w,monospace">T</span> are not template parameters.&nbsp; This keeps a 1:1 c=
orrelation between the elements of a template parameter list and elements o=
f argument lists at points of instantiation.&nbsp; That is, given a declara=
tion:<br><div style=3D"margin-left:40px"><span style=3D"font-family:courier=
 new,monospace">template using typename R, typename... Args &lt;R (* f)(Arg=
s...)&gt; struct func;</span><br></div>...the point of use looks like:<br><=
div style=3D"margin-left:40px"><span style=3D"font-family:courier new,monos=
pace">func&lt;MyFunc&gt; myfunc;</span><br></div>...and in both cases there=
's only one item in the angle brackets.</div></div></blockquote><div><br></=
div><div>I can see this being a convenience in some cases. Is it necessary =
to enable any of the other functionality, or is it only a syntactic shortha=
nd? Your example can presumably be written:</div><div><br></div><div>&nbsp;=
 template&lt;auto (*f)(auto...)&gt; struct func;</div><div><br></div><div>.=
... with a little extra work required to extract the return type and paramet=
er types from f inside the definition of 'func'.<br></div></div></div></div=
></blockquote><div><br>After reading N3601, I actually see auto as a shorth=
and notation for<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> _T </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">_T x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span></div></code></div><br=
> Template meta-parameters are more flexible and more expressive, but also =
more verbose.&nbsp; While you are correct that in your example above it is =
already possible to extract the return and parameter types using partial sp=
ecializations, template meta-parameters mean that you don't have to.&nbsp; =
Here's an example where you can't currently use partial specialization to a=
chieve the same effect:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><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: #008;" class=3D"styled-by-pr=
ettify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> R</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Args</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">R </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(*</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> F</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">...)&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>R function_wrapper</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Args</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> args</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></div></code></div><br>The function_wrappe=
r function template is parameterized on the function it wraps, and is defin=
ed as taking the same number and types of arguments as the function it is w=
rapping.&nbsp; In my paper, I achieved a similar effect by declaring a func=
tion pointer variable template that points to a static member function of a=
 partially specialized struct.&nbsp; That's a lot of indirection, made much=
 more straightforward by the declaration above.&nbsp; With template meta-pa=
rameters, there's no need for the variable template, the struct template, o=
r any partial specialization of the struct template.&nbsp; That's a <i>lot<=
/i> more convenient, and much more straightforward to read, to the point wh=
ere I'd say it justifies the feature.<br><br>All of that said, these three =
features are orthogonal; do you think it would be better to propose them se=
parately, or all at once?<br><br></div></div>

<p></p>

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

------=_Part_382_1446728788.1421055658723--
------=_Part_381_948929630.1421055658723--

.

------=_Part_310_1105981715.1421082682894
Content-Type: multipart/alternative;
 boundary="----=_Part_311_1763719220.1421082682894"

------=_Part_311_1763719220.1421082682894
Content-Type: text/plain; charset=UTF-8



On Monday, January 12, 2015 at 10:40:58 AM UTC+1, bek...@gmail.com wrote:

> All of that said, these three features are orthogonal; do you think it
> would be better to propose them separately, or all at once?
>
>
I don't think that `auto` and `using` (if you chose this keyword) are
orthogonal, second one is more generalized than first one. I think best way
would be focus on `auto` and add `using` as possible further extension.
If committee accept `auto` then they can give you feedback if they want
more generalized version too.

Third one is indeed orthogonal, It should have its own paper.

--

---
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_311_1763719220.1421082682894
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 12, 2015 at 10:40:58 AM UTC+1, =
bek...@gmail.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>All of that said, these three features are orthogonal; d=
o you think it would be better to propose them separately, or all at once?<=
br><br></div></div></blockquote><div><br>I don't think that `auto` and `usi=
ng` (if you chose this keyword) are orthogonal, second one is more generali=
zed than first one. I think best way would be focus on `auto` and add `usin=
g` as possible further extension.<br>If committee accept `auto` then they c=
an give you feedback if they want more generalized version too.<br><br>Thir=
d one is indeed orthogonal, It should have its own paper.<br></div></div>

<p></p>

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

------=_Part_311_1763719220.1421082682894--
------=_Part_310_1105981715.1421082682894--

.

------=_Part_3300_502618221.1421087012345
Content-Type: multipart/alternative;
 boundary="----=_Part_3301_152027046.1421087012351"

------=_Part_3301_152027046.1421087012351
Content-Type: text/plain; charset=UTF-8



On Monday, January 12, 2015 at 9:34:02 AM UTC+1, Richard Smith wrote:
>
>
> I can see this being a convenience in some cases. Is it necessary to
> enable any of the other functionality, or is it only a syntactic shorthand?
> Your example can presumably be written:
>
>   template<auto (*f)(auto...)> struct func;
>
> ... with a little extra work required to extract the return type and
> parameter types from f inside the definition of 'func'.
>

`auto` can be only used in place where `typename` was used. I doubt that
committee will allow `auto` inside no-type parameters.

BTW after analyzing this I get idea of variable templates as template
parameters (similar to current alias templates) but I don't know it would
be worth effort to add?

--

---
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_3301_152027046.1421087012351
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 12, 2015 at 9:34:02 AM UTC+1, R=
ichard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>I can see this be=
ing a convenience in some cases. Is it necessary to enable any of the other=
 functionality, or is it only a syntactic shorthand? Your example can presu=
mably be written:</div><div><br></div><div>&nbsp; template&lt;auto (*f)(aut=
o...)&gt; struct func;</div><div><br></div><div>... with a little extra wor=
k required to extract the return type and parameter types from f inside the=
 definition of 'func'.<br></div></div></div></div></blockquote><div><br>`au=
to` can be only used in place where `typename` was used. I doubt that commi=
ttee will allow `auto` inside no-type parameters.<br><br>BTW after analyzin=
g this I get idea of variable
  templates as template parameters (similar to current alias templates) but=
 I don't know it would be worth effort to add?<br></div></div>

<p></p>

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

------=_Part_3301_152027046.1421087012351--
------=_Part_3300_502618221.1421087012345--

.

------=_Part_2263_249358602.1421087456373
Content-Type: multipart/alternative;
 boundary="----=_Part_2264_1229428517.1421087456373"

------=_Part_2264_1229428517.1421087456373
Content-Type: text/plain; charset=UTF-8

On Monday, January 12, 2015 at 9:11:22 AM UTC-8, inkwizyt...@gmail.com
wrote:
>
> I don't think that `auto` and `using` (if you chose this keyword) are
> orthogonal, second one is more generalized than first one. I think best way
> would be focus on `auto` and add `using` as possible further extension.
> If committee accept `auto` then they can give you feedback if they want
> more generalized version too.
>
>
Either feature can be supported in the absence of the other, and the two
features have no change in meaning when used together.  That's what I meant
by orthogonal.

--

---
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_2264_1229428517.1421087456373
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 12, 2015 at 9:11:22 AM UTC-8, inkwizyt.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">I don't think that `auto` and `using` (if you chose this keyword) are=
 orthogonal, second one is more generalized than first one. I think best wa=
y would be focus on `auto` and add `using` as possible further extension.<b=
r><div>If committee accept `auto` then they can give you feedback if they w=
ant more generalized version too.<br><br></div></div></blockquote><br>Eithe=
r feature can be supported in the absence of the other, and the two feature=
s have no change in meaning when used together.&nbsp; That's what I meant b=
y orthogonal.<br></div>

<p></p>

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

------=_Part_2264_1229428517.1421087456373--
------=_Part_2263_249358602.1421087456373--

.

------=_Part_614_1453008551.1421087631801
Content-Type: multipart/alternative;
 boundary="----=_Part_615_1678166620.1421087631801"

------=_Part_615_1678166620.1421087631801
Content-Type: text/plain; charset=UTF-8

On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt...@gmail.com
wrote:
>
> BTW after analyzing this I get idea of variable templates as template
> parameters (similar to current alias templates) but I don't know it would
> be worth effort to add?
>

I think that's already in C++17, with the following syntax:
template <template <typename TT> typename T> ...

This declares a variable template template parameter T, which is in turn
parameterized on TT.

--

---
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_615_1678166620.1421087631801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>BTW after analyzing this I get idea of variable
  templates as template parameters (similar to current alias templates) but=
 I don't know it would be worth effort to add?<br></div></div></blockquote>=
<div><br>I think that's already in C++17, with the following syntax:<br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">template</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> TT</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 T</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">...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></div></code></d=
iv><br>This declares a variable template template parameter T, which is in =
turn parameterized on TT.<br></div></div>

<p></p>

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

------=_Part_615_1678166620.1421087631801--
------=_Part_614_1453008551.1421087631801--

.

------=_Part_883_1892729553.1421089362777
Content-Type: multipart/alternative;
 boundary="----=_Part_884_430334260.1421089362777"

------=_Part_884_430334260.1421089362777
Content-Type: text/plain; charset=UTF-8



On Monday, January 12, 2015 at 7:33:51 PM UTC+1, bek...@gmail.com wrote:
>
> On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt...@gmail.com
> wrote:
>>
>> BTW after analyzing this I get idea of variable templates as template
>> parameters (similar to current alias templates) but I don't know it would
>> be worth effort to add?
>>
>
> I think that's already in C++17, with the following syntax:
> template <template <typename TT> typename T> ...
>
> This declares a variable template template parameter T, which is in turn
> parameterized on TT.
>

AFAIK `typename` == `class`, this was added for "support" of alias
templates that aren't classes.

--

---
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_884_430334260.1421089362777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 12, 2015 at 7:33:51 PM UTC+1, b=
ek...@gmail.com wrote:<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">On Monday, January 12, 2015 at 10:23:32 AM UTC-8, <a>inkwizyt...@g=
mail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>BTW after analyzing this I get idea of variable
  templates as template parameters (similar to current alias templates) but=
 I don't know it would be worth effort to add?<br></div></div></blockquote>=
<div><br>I think that's already in C++17, with the following syntax:<br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#008">template</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">&lt;</span><span style=3D"color:#008">template</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><=
span style=3D"color:#008">typename</span><span style=3D"color:#000"> TT</sp=
an><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">...</span><span style=3D"color:#000"> <br></sp=
an></div></code></div><br>This declares a variable template template parame=
ter T, which is in turn parameterized on TT.<br></div></div></blockquote><d=
iv><br>AFAIK `typename` =3D=3D `class`, this was added for "support" of ali=
as templates that aren't classes.<br></div><div><code><span style=3D"color:=
#000"></span></code></div></div>

<p></p>

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

------=_Part_884_430334260.1421089362777--
------=_Part_883_1892729553.1421089362777--

.

On 12 January 2015 at 21:02,  <inkwizytoryankes@gmail.com> wrote:
>> I think that's already in C++17, with the following syntax:
>> template <template <typename TT> typename T> ...
>> This declares a variable template template parameter T, which is in turn
>> parameterized on TT.
> AFAIK `typename` == `class`, this was added for "support" of alias templates
> that aren't classes.

Well, it was added mostly because this was the only case where one had to write
class instead of typename, so we wanted to lift that requirement.

--

---
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 12 January 2015 at 21:05, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 12 January 2015 at 21:02,  <inkwizytoryankes@gmail.com> wrote:
>>> I think that's already in C++17, with the following syntax:
>>> template <template <typename TT> typename T> ...
>>> This declares a variable template template parameter T, which is in turn
>>> parameterized on TT.
>> AFAIK `typename` == `class`, this was added for "support" of alias templates
>> that aren't classes.
>
> Well, it was added mostly because this was the only case where one had to write
> class instead of typename, so we wanted to lift that requirement.

Ah, yes, http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4051.html
mentions alias templates and such non-class things as rationale.

--

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

.

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

My mistake; thanks for the correction.

On Mon, Jan 12, 2015 at 11:06 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 12 January 2015 at 21:05, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 12 January 2015 at 21:02,  <inkwizytoryankes@gmail.com> wrote:
> >>> I think that's already in C++17, with the following syntax:
> >>> template <template <typename TT> typename T> ...
> >>> This declares a variable template template parameter T, which is in
> turn
> >>> parameterized on TT.
> >> AFAIK `typename` == `class`, this was added for "support" of alias
> templates
> >> that aren't classes.
> >
> > Well, it was added mostly because this was the only case where one had
> to write
> > class instead of typename, so we wanted to lift that requirement.
>
> Ah, yes, http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4051.html
> mentions alias templates and such non-class things as rationale.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.

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

<div dir=3D"ltr">My mistake; thanks for the correction.</div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jan 12, 2015 at 11:06 A=
M, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilai=
nen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On 12 January 2015 at 21:05, Vill=
e Voutilainen<br>
<span>&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@=
gmail.com</a>&gt; wrote:<br>
&gt; On 12 January 2015 at 21:02,=C2=A0 &lt;<a href=3D"mailto:inkwizytoryan=
kes@gmail.com">inkwizytoryankes@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; I think that&#39;s already in C++17, with the following syntax=
:<br>
&gt;&gt;&gt; template &lt;template &lt;typename TT&gt; typename T&gt; ...<b=
r>
&gt;&gt;&gt; This declares a variable template template parameter T, which =
is in turn<br>
&gt;&gt;&gt; parameterized on TT.<br>
&gt;&gt; AFAIK `typename` =3D=3D `class`, this was added for &quot;support&=
quot; of alias templates<br>
&gt;&gt; that aren&#39;t classes.<br>
&gt;<br>
&gt; Well, it was added mostly because this was the only case where one had=
 to write<br>
&gt; class instead of typename, so we wanted to lift that requirement.<br>
<br>
</span>Ah, yes, <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2=
014/n4051.html" target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/docs/p=
apers/2014/n4051.html</a><br>
mentions alias templates and such non-class things as rationale.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--bcaec550ac8818da6c050c797c03--

.

--001a11c380707a5f43050c7a05f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 12, 2015 at 10:33 AM,  <bekenn@gmail.com> wrote:
> On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt...@gmail.com
wrote:
>>
>> BTW after analyzing this I get idea of variable templates as template
>> parameters (similar to current alias templates) but I don't know it
would be
>> worth effort to add?
>
> I think that's already in C++17, with the following syntax:
> template <template <typename TT> typename T> ...
>
> This declares a variable template template parameter T, which is in turn
> parameterized on TT.

Not quite. The template template parameter T there is still a type template
(as indicated by "typename T"), not a variable template. The syntax for
variable template template parameters ought to be

    template<template<typename T> int variable_template> ...

as in,

    template<typename T> T pi =3D static_cast<T>(3.14);
    template<template<typename T> T P> int int_plus_one =3D P<int> + 1;
    int main()
    {
        return int_plus_one<pi>;  // which is pi<int> + 1, which is 4
    }

I'm not aware of any online compiler that accepts variable templates yet,
nor does my local compiler, so I haven't tested this C++1z code.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Mon, Jan 12, 2015 at 10:33 AM, =C2=A0&lt;<a href=3D"mai=
lto:bekenn@gmail.com">bekenn@gmail.com</a>&gt; wrote:<br>&gt; On Monday, Ja=
nuary 12, 2015 at 10:23:32 AM UTC-8, <a href=3D"mailto:inkwizyt...@gmail.co=
m">inkwizyt...@gmail.com</a> wrote:<br>&gt;&gt;<br>&gt;&gt; BTW after analy=
zing this I get idea of variable templates as template<br>&gt;&gt; paramete=
rs (similar to current alias templates) but I don&#39;t know it would be<br=
>&gt;&gt; worth effort to add?<br>&gt;<br>&gt; I think that&#39;s already i=
n C++17, with the following syntax:<br>&gt; template &lt;template &lt;typen=
ame TT&gt; typename T&gt; ...<br>&gt;<br>&gt; This declares a variable temp=
late template parameter T, which is in turn<br>&gt; parameterized on TT.<br=
><br>Not quite. The template template parameter T there is still a type tem=
plate (as indicated by &quot;typename T&quot;), not a variable template. Th=
e syntax for variable template template parameters ought to be<div><br></di=
v><div><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 templa=
te&lt;template&lt;typename T&gt; int variable_template&gt; ...</span><br st=
yle=3D"font-family:monospace,monospace"></div><div><br></div><div>as in,<br=
><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;typename=
 T&gt; T pi =3D static_cast&lt;T&gt;(3.14);<br>=C2=A0 =C2=A0 template&lt;te=
mplate&lt;typename T&gt; T P&gt; int int_plus_one =3D P&lt;int&gt; + 1;<br>=
=C2=A0 =C2=A0 int main()</font><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return int_plus_one&lt;pi&gt;; =
=C2=A0// which is pi&lt;int&gt; + 1, which is 4<br>=C2=A0 =C2=A0 }</font><d=
iv><br>I&#39;m not aware of any online compiler that accepts variable templ=
ates yet, nor does my local compiler, so I haven&#39;t tested this C++1z co=
de.</div><div><br></div></div></div><div>=E2=80=93Arthur</div></div>

<p></p>

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

--001a11c380707a5f43050c7a05f4--

.

------=_Part_947_507341453.1421105361168
Content-Type: multipart/alternative;
 boundary="----=_Part_948_1377721981.1421105361168"

------=_Part_948_1377721981.1421105361168
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Monday, January 12, 2015 at 3:05:03 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Mon, Jan 12, 2015 at 10:33 AM,  <bek...@gmail.com <javascript:>> wrote=
:
> > On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt...@gmail.com=
=20
> wrote:
> >>
> >> BTW after analyzing this I get idea of variable templates as template
> >> parameters (similar to current alias templates) but I don't know it=20
> would be
> >> worth effort to add?
> >
> > I think that's already in C++17, with the following syntax:
> > template <template <typename TT> typename T> ...
> >
> > This declares a variable template template parameter T, which is in tur=
n
> > parameterized on TT.
>
> Not quite. The template template parameter T there is still a type=20
> template (as indicated by "typename T"), not a variable template. The=20
> syntax for variable template template parameters ought to be
>
>     template<template<typename T> int variable_template> ...
>
> as in,
>
>     template<typename T> T pi =3D static_cast<T>(3.14);
>     template<template<typename T> T P> int int_plus_one =3D P<int> + 1;
>     int main()
>     {
>         return int_plus_one<pi>;  // which is pi<int> + 1, which is 4
>     }
>
> I'm not aware of any online compiler that accepts variable templates yet,=
=20
> nor does my local compiler, so I haven't tested this C++1z code.
>
> =E2=80=93Arthur
>

Is this a C++17 concept? Far as I know, variable templates may not be=20
referred to without a "<T>" specifier and we have no way using a variable=
=20
template, which may not necessarily be constexpr, as a template template=20
argument, and also a variable template need not be the same type as its=20
type argument. For example:


template<class T, class U> constexpr bool is_same =3D false;
template<class T> constexpr bool is_same<T,T> =3D true;

int main()
{
  return is_same<int,float>;
}

(clang can compile this with `-std=3Dc++14`)

A little off-topic in this thread, but being able to pass a variable=20
template as a parameter when the type parameter is unknown would be nice.=
=20
It would make them much more useful in template meta-programming.

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

------=_Part_948_1377721981.1421105361168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 12, 2015 at 3:05:03 PM UTC-5, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Mon, Jan 12, 2015 at 10:33 AM, &nbsp;&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"vN9erblflkMJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">bek...@gmail.com</a>&gt; wrote:<br>&gt; On Monday, January 1=
2, 2015 at 10:23:32 AM UTC-8, <a>inkwizyt...@gmail.com</a> wrote:<br>&gt;&g=
t;<br>&gt;&gt; BTW after analyzing this I get idea of variable templates as=
 template<br>&gt;&gt; parameters (similar to current alias templates) but I=
 don't know it would be<br>&gt;&gt; worth effort to add?<br>&gt;<br>&gt; I =
think that's already in C++17, with the following syntax:<br>&gt; template =
&lt;template &lt;typename TT&gt; typename T&gt; ...<br>&gt;<br>&gt; This de=
clares a variable template template parameter T, which is in turn<br>&gt; p=
arameterized on TT.<br><br>Not quite. The template template parameter T the=
re is still a type template (as indicated by "typename T"), not a variable =
template. The syntax for variable template template parameters ought to be<=
div><br></div><div><span style=3D"font-family:monospace,monospace">&nbsp; &=
nbsp; template&lt;template&lt;typename T&gt; int variable_template&gt; ...<=
/span><br style=3D"font-family:monospace,monospace"></div><div><br></div><d=
iv>as in,<br><br><font face=3D"monospace, monospace">&nbsp; &nbsp; template=
&lt;typename T&gt; T pi =3D static_cast&lt;T&gt;(3.14);<br>&nbsp; &nbsp; te=
mplate&lt;template&lt;typename T&gt; T P&gt; int int_plus_one =3D P&lt;int&=
gt; + 1;<br>&nbsp; &nbsp; int main()</font><div><font face=3D"monospace, mo=
nospace">&nbsp; &nbsp; {<br>&nbsp; &nbsp; &nbsp; &nbsp; return int_plus_one=
&lt;pi&gt;; &nbsp;// which is pi&lt;int&gt; + 1, which is 4<br>&nbsp; &nbsp=
; }</font><div><br>I'm not aware of any online compiler that accepts variab=
le templates yet, nor does my local compiler, so I haven't tested this C++1=
z code.</div><div><br></div></div></div><div>=E2=80=93Arthur</div></div></b=
lockquote><div><br></div><div>Is this a C++17 concept? Far as I know, varia=
ble&nbsp;<span style=3D"font-size: 13.3333339691162px;">templates may not b=
e referred to without a "&lt;T&gt;" specifier and we have no way using a va=
riable template, which may not necessarily be constexpr, as a template temp=
late argument, and also a variable template need not be the same type as it=
s type argument. For example:</span></div><div><span style=3D"font-size: 13=
px;"><br></span></div><div><br></div><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> U</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
stexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> is_same </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">false</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: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> is_same</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">true</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;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-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; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i=
s_same</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></div>=
<div><span style=3D"font-size: 13px;">(clang can compile this with `-std=3D=
c++14`)</span></div><div><span style=3D"font-size: 13px;"><br></span></div>=
<div><span style=3D"font-size: 13px;">A little off-topic in this thread, bu=
t being able to pass a variable template as a parameter when the type param=
eter is unknown would be nice. It would make them much more useful in templ=
ate meta-programming.</span><br></div></div>

<p></p>

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

------=_Part_948_1377721981.1421105361168--
------=_Part_947_507341453.1421105361168--

.

--f46d044280747ce594050c7d528c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 12, 2015 at 3:29 PM, Scott Prager <splinterofchaos@gmail.com>
wrote:

> On Monday, January 12, 2015 at 3:05:03 PM UTC-5, Arthur O'Dwyer wrote:
>>
>> On Mon, Jan 12, 2015 at 10:33 AM,  <bek...@gmail.com> wrote:
>> > On Monday, January 12, 2015 at 10:23:32 AM UTC-8, inkwizyt...@gmail.co=
m
>> wrote:
>> >>
>> >> BTW after analyzing this I get idea of variable templates as template
>> >> parameters (similar to current alias templates) but I don't know it
>> would be
>> >> worth effort to add?
>> >
>> > I think that's already in C++17, with the following syntax:
>> > template <template <typename TT> typename T> ...
>> >
>> > This declares a variable template template parameter T, which is in tu=
rn
>> > parameterized on TT.
>>
>> Not quite. The template template parameter T there is still a type
>> template (as indicated by "typename T"), not a variable template. The
>> syntax for variable template template parameters ought to be
>>
>>     template<template<typename T> int variable_template> ...
>>
>> as in,
>>
>>     template<typename T> T pi =3D static_cast<T>(3.14);
>>     template<template<typename T> T P> int int_plus_one =3D P<int> + 1;
>>     int main()
>>     {
>>         return int_plus_one<pi>;  // which is pi<int> + 1, which is 4
>>     }
>>
>> I'm not aware of any online compiler that accepts variable templates yet=
,
>> nor does my local compiler, so I haven't tested this C++1z code.
>>
>
> Is this a C++17 concept? Far as I know, variable templates may not be
> referred to without a "<T>" specifier and we have no way using a variable
> template, which may not necessarily be constexpr, as a template template
> argument, and also a variable template need not be the same type as its
> type argument. For example:
>
>
> template<class T, class U> constexpr bool is_same =3D false;
> template<class T> constexpr bool is_same<T,T> =3D true;
>
> int main()
> {
>   return is_same<int,float>;
> }
>

Scott, you're correct on all counts.
- My untested code "ought to be" correct, but indeed it's not valid C++17
(yet?). GCC-trunk rejects it.
- Variable templates need not be constexpr; but that is a red herring. My
code "ought to" work without constexpr.
- A variable template's specialization(s) need not have the same type as
the template's type parameter; but that is a red herring. In my example,
pi<T> *does* happen to be of type T, even though it could equally well be
of any other type.

For example, in your code, it would be nice to be able to express:

    template<class T, class U> constexpr bool is_same =3D false;
    template<class T> constexpr bool is_same<T,T> =3D true;

    template<template<class...> bool P> bool true_for_int_int =3D P<int,int=
>;
    template<template<class...> bool P> bool true_for_int_double =3D
P<int,double>;

    int main()
    {
        return true_for_int_double<is_same>;
    }

I thought that with the introduction of variable templates in C++17, we'd
get this feature for free. Apparently it still needs working-out.  From
N3651 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>:

   -

   A plurality of EWG felt that uses of variable templates as template
   template argument should be done separately, not for C++14.

So, my mistake; variable template template parameters are not part of C++1z
as it stands today. But the syntax they'll occupy *when* they arrive is
pretty obvious.
(This is completely unrelated to 'template<auto ...>', by the way. :))

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Mon, Jan 12, 2015 at 3:29 PM, Scott Prager <span dir=3D=
"ltr">&lt;<a href=3D"mailto:splinterofchaos@gmail.com" target=3D"_blank">sp=
linterofchaos@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Monday, Ja=
nuary 12, 2015 at 3:05:03 PM UTC-5, Arthur O&#39;Dwyer wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr">On Mon, Jan 12, 2015 at 10:33 AM, =C2=A0&lt;<a>bek...@g=
mail.com</a>&gt; wrote:<br>&gt; On Monday, January 12, 2015 at 10:23:32 AM =
UTC-8, <a>inkwizyt...@gmail.com</a> wrote:<br>&gt;&gt;<br>&gt;&gt; BTW afte=
r analyzing this I get idea of variable templates as template<br>&gt;&gt; p=
arameters (similar to current alias templates) but I don&#39;t know it woul=
d be<br>&gt;&gt; worth effort to add?<br>&gt;<br>&gt; I think that&#39;s al=
ready in C++17, with the following syntax:<br>&gt; template &lt;template &l=
t;typename TT&gt; typename T&gt; ...<br>&gt;<br>&gt; This declares a variab=
le template template parameter T, which is in turn<br>&gt; parameterized on=
 TT.<br><br>Not quite. The template template parameter T there is still a t=
ype template (as indicated by &quot;typename T&quot;), not a variable templ=
ate. The syntax for variable template template parameters ought to be<div><=
br></div><div><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0=
 template&lt;template&lt;typename T&gt; int variable_template&gt; ...</span=
><br style=3D"font-family:monospace,monospace"></div><div><br></div><div>as=
 in,<br><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;t=
ypename T&gt; T pi =3D static_cast&lt;T&gt;(3.14);<br>=C2=A0 =C2=A0 templat=
e&lt;template&lt;typename T&gt; T P&gt; int int_plus_one =3D P&lt;int&gt; +=
 1;<br>=C2=A0 =C2=A0 int main()</font><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return int_plus_one&lt;p=
i&gt;; =C2=A0// which is pi&lt;int&gt; + 1, which is 4<br>=C2=A0 =C2=A0 }</=
font><div><br>I&#39;m not aware of any online compiler that accepts variabl=
e templates yet, nor does my local compiler, so I haven&#39;t tested this C=
++1z code.</div></div></div></div></blockquote><div><br></div><div>Is this =
a C++17 concept? Far as I know, variable=C2=A0<span style=3D"font-size:13.3=
333339691162px">templates may not be referred to without a &quot;&lt;T&gt;&=
quot; specifier and we have no way using a variable template, which may not=
 necessarily be constexpr, as a template template argument, and also a vari=
able template need not be the same type as its type argument. For example:<=
/span></div><div><span style=3D"font-size:13px"><br></span></div><div><br><=
/div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;b=
ackground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,1=
36)">template</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span s=
tyle=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> T=
</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rg=
b(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><span styl=
e=3D"color:rgb(0,0,0)"> U</span><span style=3D"color:rgb(102,102,0)">&gt;</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,=
136)">constexpr</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">bool</span><span style=3D"color:rgb(0,0,0)"> is_sam=
e </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">false</span><span =
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br=
></span><span style=3D"color:rgb(0,0,136)">template</span><span style=3D"co=
lor:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,136)">class</sp=
an><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,1=
02,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(0,0,136)">constexpr</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(0,0,136)">bool</span><span style=3D"color:rgb(0,0=
,0)"> is_same</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span s=
tyle=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,102,0)">,</s=
pan><span style=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,1=
02,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><sp=
an style=3D"color:rgb(0,0,136)">true</span><span style=3D"color:rgb(102,102=
,0)">;</span><span style=3D"color:rgb(0,0,0)"><br><br></span><span style=3D=
"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> main</span=
><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0=
,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D=
"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">ret=
urn</span><span style=3D"color:rgb(0,0,0)"> is_same</span><span style=3D"co=
lor:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,136)">int</span=
><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,=
136)">float</span><span style=3D"color:rgb(102,102,0)">&gt;;</span><span st=
yle=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}<=
/span></div></code></div></div></blockquote><div><br></div><div>Scott, you&=
#39;re correct on all counts.</div><div>- My untested code &quot;ought to b=
e&quot; correct, but indeed it&#39;s not valid C++17 (yet?). GCC-trunk reje=
cts it.</div><div>- Variable templates need not be constexpr; but that is a=
 red herring. My code &quot;ought to&quot; work without constexpr.</div><di=
v>- A variable template&#39;s specialization(s) need not have the same type=
 as the template&#39;s type parameter; but that is a red herring. In my exa=
mple, <font face=3D"monospace, monospace">pi&lt;T&gt;</font> <i>does</i> ha=
ppen to be of type <font face=3D"monospace, monospace">T</font>, even thoug=
h it could equally well be of any other type.</div><div><br></div><div>For =
example, in your code, it would be nice to be able to express:</div><div><b=
r></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;=
class T, class U&gt; constexpr bool is_same =3D false;</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;class T&gt; cons=
texpr bool is_same&lt;T,T&gt; =3D true;</font></div><div><font face=3D"mono=
space, monospace"><br></font></div><div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 template&lt;template&lt;class...&gt; bool P&gt; bool tr=
ue_for_int_int =3D P&lt;int,int&gt;;</font></div></div><div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;template&lt;class...&gt=
; bool P&gt; bool true_for_int_double =3D P&lt;int,double&gt;;</font></div>=
</div><div><font face=3D"monospace, monospace"><br></font></div><div><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 int main()<br></font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 {</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return true_for_=
int_double&lt;is_same&gt;;</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 }</font></div><div><br></div><div>I thought that with th=
e introduction of variable templates in C++17, we&#39;d get this feature fo=
r free. Apparently it still needs working-<font face=3D"arial, helvetica, s=
ans-serif">out.=C2=A0 From <a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2013/n3651.pdf">N3651</a>:</font></div><div>
 =09
=09
=09
  <div class=3D"" title=3D"Page 8">
   <div class=3D"">
    <div class=3D"">
     <ul>
      <li>
       <p><font face=3D"arial, helvetica, sans-serif">A plurality of EWG fe=
lt that uses of variable templates as template template
argument should be done separately, not for C++14.</font></p></li></ul></di=
v></div></div></div><div><font face=3D"arial, helvetica, sans-serif">So, my=
 mistake; variable template template parameters are not part of C++1z as it=
 stands today. But the syntax they&#39;ll occupy <i>when</i> they arrive is=
 pretty obvious.</font></div><div><font face=3D"arial, helvetica, sans-seri=
f">(This is completely unrelated to &#39;template&lt;auto ...&gt;&#39;, by =
the way. :))</font></div><div><font face=3D"arial, helvetica, sans-serif"><=
br></font></div><div><font face=3D"arial, helvetica, sans-serif">=E2=80=93A=
rthur</font></div></div></div></div>

<p></p>

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

--f46d044280747ce594050c7d528c--

.

--Apple-Mail=_851700D7-CF1C-4A9F-BA17-DE83AA6E69AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager <splinterofchaos@=
gmail.com> wrote:
>=20
> A little off-topic in this thread, but being able to pass a variable temp=
late as a parameter when the type parameter is unknown would be nice. It wo=
uld make them much more useful in template meta-programming.

Is there a real use-case? Variable templates are a convenience, but they=E2=
=80=99re not primitive. You can emulate them with class-based metafunctions=
.. Passing a variable template as a metafunction likewise only requires a wr=
apper class.

Applying this solution to the previous (unrealistic) example,

template<typename T> T pi =3D static_cast<T>(3.14);

template< typename T >
struct pi_as_metafunction {
    static T const & value =3D pi< T >;
};

template<template<typename T> class P> int int_plus_one =3D P<int>::value +=
 1;

int main()
{
    return int_plus_one<pi_as_metafunction>;  // which is pi<int> + 1, whic=
h is 4
}

What this doesn=E2=80=99t support is partial specialization, i.e. recoverin=
g the int parameter from pi<int>. However, is that something we really want=
? It would support such abuse as,

template< int const & obj >
struct is_typename_parameterized : std::false_type {};

template< template< typename type > int const & templ, typename param >
struct is_typename_parameterized< templ< param > > : std::true_type {};

int x;
constexpr int const * nums[] =3D { & x, & pi< int > };

static_assert( ! is_typename_parameterized< * nums[0] >();
static_assert( is_typename_parameterized< * nums[1] >();

Having the computed address of a variable template specialization behave di=
fferently from the template-id of the specialization would introduce yet an=
other kind of expression: more complicated rules to support corner cases of=
 more arcane syntax.

Metaprogramming is complicated enough using the identities and properties o=
f types. Sending different variables into different templates is madness, a=
nd not something to be made more convenient. (It is already possible to do =
this sort of thing using SFINAE and wrapper classes, so we=E2=80=99re not e=
ven talking about added capability.)

Likewise, we=E2=80=99ve had function templates for a long time, but nobody =
ever wishes for template parameters that are unspecialized function templat=
es.

The C++ template system is the last place we should be pursuing solutions i=
n search of a problem.

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

--Apple-Mail=_851700D7-CF1C-4A9F-BA17-DE83AA6E69AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9313, at 7:29 AM, Scott Prager &lt;<a href=3D"mailto:splinterofchaos=
@gmail.com" class=3D"">splinterofchaos@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-famil=
y: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; f=
loat: none; display: inline !important;" class=3D"">A little off-topic in t=
his thread, but being able to pass a variable template as a parameter when =
the type parameter is unknown would be nice. It would make them much more u=
seful in template meta-programming.</span></div></blockquote></div><br clas=
s=3D""><div class=3D"">Is there a real use-case? Variable templates are a c=
onvenience, but they=E2=80=99re not primitive. You can emulate them with cl=
ass-based metafunctions. Passing a variable template as a metafunction like=
wise only requires a wrapper class.</div><div class=3D""><br class=3D""></d=
iv><div class=3D"">Applying this solution to the previous (unrealistic) exa=
mple,</div><div class=3D""><br class=3D""></div><div class=3D""><font face=
=3D"Courier" class=3D"">template&lt;typename T&gt; T pi =3D static_cast&lt;=
T&gt;(3.14);</font></div><div class=3D""><font face=3D"Courier" class=3D"">=
<br class=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D=
"">template&lt; typename T &gt;</font></div><div class=3D""><font face=3D"C=
ourier" class=3D"">struct pi_as_metafunction {</font></div><div class=3D"">=
<font face=3D"Courier" class=3D"">&nbsp; &nbsp; static T const &amp; value =
=3D pi&lt; T &gt;;</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">};</font></div><div class=3D""><font face=3D"Courier" class=3D""><br =
class=3D"">template&lt;template&lt;typename T&gt; class P&gt; int int_plus_=
one =3D P&lt;int&gt;::value + 1;</font></div><div class=3D""><font face=3D"=
Courier" class=3D""><br class=3D"">int main()<br class=3D"">{<br class=3D""=
>&nbsp; &nbsp; return int_plus_one&lt;pi_as_metafunction&gt;; &nbsp;// whic=
h is pi&lt;int&gt; + 1, which is 4<br class=3D"">}<br class=3D""></font></d=
iv><div class=3D""><br class=3D""></div><div class=3D"">What this doesn=E2=
=80=99t support is partial specialization, i.e. recovering the int paramete=
r from <font face=3D"Courier" class=3D"">pi&lt;int&gt;</font>. However, is =
that something we really want? It would support such abuse as,</div><div cl=
ass=3D""><br class=3D""></div><div class=3D""><font face=3D"Courier" class=
=3D"">template&lt; int const &amp; obj &gt;</font></div><div class=3D""><fo=
nt face=3D"Courier" class=3D"">struct is_typename_parameterized : std::fals=
e_type {};</font></div><div class=3D""><font face=3D"Courier" class=3D""><b=
r class=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D""=
>template&lt; template&lt; typename type &gt; int const &amp; templ, typena=
me param &gt;</font></div><div class=3D""><font face=3D"Courier" class=3D""=
>struct is_typename_parameterized&lt;&nbsp;templ&lt; param &gt; &gt;</font>=
<span style=3D"font-family: Courier;" class=3D"">&nbsp;</span><span style=
=3D"font-family: Courier;" class=3D"">: std::true_type {};</span></div><div=
 class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><=
div class=3D""><font face=3D"Courier" class=3D"">int x;</font></div><div cl=
ass=3D""><font face=3D"Courier" class=3D"">constexpr int const * nums[] =3D=
 { &amp; x, &amp; pi&lt; int &gt; };</font></div><div class=3D""><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><font f=
ace=3D"Courier" class=3D"">static_assert( ! is_typename_parameterized&lt; *=
 nums[0] &gt;();</font></div><div class=3D""><div class=3D""><font face=3D"=
Courier" class=3D"">static_assert( is_typename_parameterized&lt; * nums[1] =
&gt;();</font></div></div><div class=3D""><br class=3D""></div><div class=
=3D"">Having the computed address of a variable template specialization beh=
ave differently from the template-id of the specialization would introduce =
yet another kind of expression: more complicated rules to support corner ca=
ses of more arcane syntax.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Metaprogramming is complicated enough using the identities and pr=
operties of types. Sending different variables into different templates is =
madness, and not something to be made more convenient. (It is already possi=
ble to do this sort of thing using SFINAE and wrapper classes, so we=E2=80=
=99re not even talking about added capability.)</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">Likewise, we=E2=80=99ve had function templat=
es for a long time, but nobody ever wishes for template parameters that are=
 unspecialized function templates.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">The C++ template system is the last place we should be pu=
rsuing solutions in search of a problem.</div></body></html>

<p></p>

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

--Apple-Mail=_851700D7-CF1C-4A9F-BA17-DE83AA6E69AE--

.

Scott Prager <splinterofchaos@gmail.com> writes:

[...]

| Is this a C++17 concept? Far as I know, variable=C2=A0templates may not b=
e
| referred to without a "<T>" specifier and we have no way using a
| variable template,

That is an unfortunate restriction.

The original proposal did allow using variable template as template
template argument.  But that part didn't graduate from EWG.

-- Gaby

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

.

------=_Part_4841_375993440.1421175632549
Content-Type: multipart/alternative;
 boundary="----=_Part_4842_1424856606.1421175632549"

------=_Part_4842_1424856606.1421175632549
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Monday, January 12, 2015 at 9:25:33 PM UTC-5, David Krauss wrote:
>
>
> On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager <splinte...@gmail=
..com=20
> <javascript:>> wrote:
>
> A little off-topic in this thread, but being able to pass a variable=20
> template as a parameter when the type parameter is unknown would be nice.=
=20
> It would make them much more useful in template meta-programming.
>
>
> Is there a real use-case? Variable templates are a convenience, but=20
> they=E2=80=99re not primitive. You can emulate them with class-based meta=
functions.=20
> Passing a variable template as a metafunction likewise only requires a=20
> wrapper class.
>

I'm not quite sure because I haven't toyed with them much, but I'd like to=
=20
see a C++ where template meta-programming is possible using only `using`=20
and variable templates. That is, without creating overly verbose classes.

For a totally fantastical and implausible example,

template<bool Pred=3Dfalse, typename T=3Dvoid>
using enable_if_t;


template<typename T>
using enable_if_t<true, T> =3D T;


template<typename T>
constexpr bool isInt =3D std::is_same_v<T, int>;


template<auto TypePred, typename T>
enable_if_t<TypePred<T>, T> enabled_when(T t) { ... };


auto x =3D enabled_when<isInt>(...);

Though it's rather difficult to imagine what the syntax would look like=20
without abusing `auto`. Not even sure if I'll find much use for variable=20
templates by the time mainline gcc supports them.
=20

>
> Applying this solution to the previous (unrealistic) example,
>
> template<typename T> T pi =3D static_cast<T>(3.14);
>
> template< typename T >
> struct pi_as_metafunction {
>     static T const & value =3D pi< T >;
> };
>
> template<template<typename T> class P> int int_plus_one =3D P<int>::value=
 +=20
> 1;
>
> int main()
> {
>     return int_plus_one<pi_as_metafunction>;  // which is pi<int> + 1,=20
> which is 4
> }
>
> What this doesn=E2=80=99t support is partial specialization, i.e. recover=
ing the=20
> int parameter from pi<int>. However, is that something we really want? It=
=20
> would support such abuse as,
>
> template< int const & obj >
> struct is_typename_parameterized : std::false_type {};
>
> template< template< typename type > int const & templ, typename param >
> struct is_typename_parameterized< templ< param > > : std::true_type {};
>
> int x;
> constexpr int const * nums[] =3D { & x, & pi< int > };
>
> static_assert( ! is_typename_parameterized< * nums[0] >();
> static_assert( is_typename_parameterized< * nums[1] >();
>
> Having the computed address of a variable template specialization behave=
=20
> differently from the template-id of the specialization would introduce ye=
t=20
> another kind of expression: more complicated rules to support corner case=
s=20
> of more arcane syntax.
>
> Metaprogramming is complicated enough using the identities and properties=
=20
> of types. Sending different variables into different templates is madness=
,=20
> and not something to be made more convenient. (It is already possible to =
do=20
> this sort of thing using SFINAE and wrapper classes, so we=E2=80=99re not=
 even=20
> talking about added capability.)
>
> Likewise, we=E2=80=99ve had function templates for a long time, but nobod=
y ever=20
> wishes for template parameters that are unspecialized function templates.
>
> The C++ template system is the last place we should be pursuing solutions=
=20
> in search of a problem.
>

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

------=_Part_4842_1424856606.1421175632549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 12, 2015 at 9:25:33 PM UTC-5, D=
avid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=
=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"UCdpWiq1BU8J" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">splinte...@gmail.com</a>&gt; wrote:</div><br><div><span styl=
e=3D"font-family:Helvetica;font-size:13px;font-style:normal;font-variant:no=
rmal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;float:none;display:inline!important">A little off-topic in this thread,=
 but being able to pass a variable template as a parameter when the type pa=
rameter is unknown would be nice. It would make them much more useful in te=
mplate meta-programming.</span></div></blockquote></div><br><div>Is there a=
 real use-case? Variable templates are a convenience, but they=E2=80=99re n=
ot primitive. You can emulate them with class-based metafunctions. Passing =
a variable template as a metafunction likewise only requires a wrapper clas=
s.</div></div></blockquote><div><br></div><div>I'm not quite sure because I=
 haven't toyed with them much, but I'd like to see a C++ where template met=
a-programming is possible using only `using` and variable templates. That i=
s, without creating overly verbose classes.</div><div><br></div><div>For a =
totally fantastical and implausible example,</div><div><br></div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Pred</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">u=
sing</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> enabl=
e_if_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> enable_if_t</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">true</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> isI=
nt </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">is_same_v</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</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"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">TypePred</span><sp=
an 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">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>enable_if_t</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">TypePred</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> enabled_w=
hen</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T t</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: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> enabled_when</span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">&lt;isInt&gt;</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span></div><=
/code></div><div><br></div><div>Though it's rather difficult to imagine wha=
t the syntax would look like without abusing `auto`. Not even sure if I'll =
find much use for variable templates by the time mainline gcc supports them=
..</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div s=
tyle=3D"word-wrap:break-word"><div><br></div><div>Applying this solution to=
 the previous (unrealistic) example,</div><div><br></div><div><font face=3D=
"Courier">template&lt;typename T&gt; T pi =3D static_cast&lt;T&gt;(3.14);</=
font></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"=
Courier">template&lt; typename T &gt;</font></div><div><font face=3D"Courie=
r">struct pi_as_metafunction {</font></div><div><font face=3D"Courier">&nbs=
p; &nbsp; static T const &amp; value =3D pi&lt; T &gt;;</font></div><div><f=
ont face=3D"Courier">};</font></div><div><font face=3D"Courier"><br>templat=
e&lt;template&lt;typename T&gt; class P&gt; int int_plus_one =3D P&lt;int&g=
t;::value + 1;</font></div><div><font face=3D"Courier"><br>int main()<br>{<=
br>&nbsp; &nbsp; return int_plus_one&lt;pi_as_<wbr>metafunction&gt;; &nbsp;=
// which is pi&lt;int&gt; + 1, which is 4<br>}<br></font></div><div><br></d=
iv><div>What this doesn=E2=80=99t support is partial specialization, i.e. r=
ecovering the int parameter from <font face=3D"Courier">pi&lt;int&gt;</font=
>. However, is that something we really want? It would support such abuse a=
s,</div><div><br></div><div><font face=3D"Courier">template&lt; int const &=
amp; obj &gt;</font></div><div><font face=3D"Courier">struct is_typename_pa=
rameterized : std::false_type {};</font></div><div><font face=3D"Courier"><=
br></font></div><div><font face=3D"Courier">template&lt; template&lt; typen=
ame type &gt; int const &amp; templ, typename param &gt;</font></div><div><=
font face=3D"Courier">struct is_typename_parameterized&lt;&nbsp;<wbr>templ&=
lt; param &gt; &gt;</font><span style=3D"font-family:Courier">&nbsp;</span>=
<span style=3D"font-family:Courier">: std::true_type {};</span></div><div><=
font face=3D"Courier"><br></font></div><div><font face=3D"Courier">int x;</=
font></div><div><font face=3D"Courier">constexpr int const * nums[] =3D { &=
amp; x, &amp; pi&lt; int &gt; };</font></div><div><font face=3D"Courier"><b=
r></font></div><div><font face=3D"Courier">static_assert( ! is_typename_par=
ameterized&lt; * nums[0] &gt;();</font></div><div><div><font face=3D"Courie=
r">static_assert( is_typename_parameterized&lt; * nums[1] &gt;();</font></d=
iv></div><div><br></div><div>Having the computed address of a variable temp=
late specialization behave differently from the template-id of the speciali=
zation would introduce yet another kind of expression: more complicated rul=
es to support corner cases of more arcane syntax.</div><div><br></div><div>=
Metaprogramming is complicated enough using the identities and properties o=
f types. Sending different variables into different templates is madness, a=
nd not something to be made more convenient. (It is already possible to do =
this sort of thing using SFINAE and wrapper classes, so we=E2=80=99re not e=
ven talking about added capability.)</div><div><br></div><div>Likewise, we=
=E2=80=99ve had function templates for a long time, but nobody ever wishes =
for template parameters that are unspecialized function templates.</div><di=
v><br></div><div>The C++ template system is the last place we should be pur=
suing solutions in search of a problem.</div></div></blockquote></div>

<p></p>

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

------=_Part_4842_1424856606.1421175632549--
------=_Part_4841_375993440.1421175632549--

.

--Apple-Mail=_3B5C566A-C136-443A-B8CB-48D36B970C0D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9314, at 3:00 AM, Scott Prager <splinterofchaos@=
gmail.com> wrote:
>=20
> I'm not quite sure because I haven't toyed with them much, but I'd like t=
o see a C++ where template meta-programming is possible using only `using` =
and variable templates. That is, without creating overly verbose classes.

Yes, but what problem domain?

We=E2=80=99re just speculating, there=E2=80=99s no need to toy with an impl=
ementation.

> For a totally fantastical and implausible example,

But why? It=E2=80=99s not really productive to make suggestions just becaus=
e they look weird.

> template<auto TypePred, typename T>
> enable_if_t<TypePred<T>, T> enabled_when(T t) { ... };

The gain in this example is to replace template< typename > class with auto=
.. But that=E2=80=99s not compatible with the proposal at hand.

Adding variable template template parameters would only allow replacing tem=
plate< typename > class with template< typename > bool, and that=E2=80=99s =
not much of a gain at all. Fortunately, template template parameters are ve=
ry seldom needed.

The difference in verboseness between a class and a variable template is al=
so modest, in case you might ever need the class template.

template<typename T>
constexpr bool isInt =3D std::is_same_v<T, int>;

template<typename T>
struct isInt : std::integral_constant< bool, std::is_same_v<T, int> >;

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

--Apple-Mail=_3B5C566A-C136-443A-B8CB-48D36B970C0D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9314, at 3:00 AM, Scott Prager &lt;<a href=3D"mailto:splinterofchaos=
@gmail.com" class=3D"">splinterofchaos@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
 normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px;" class=3D"">I'm not quite sure because I haven't toyed with them =
much, but I'd like to see a C++ where template meta-programming is possible=
 using only `using` and variable templates. That is, without creating overl=
y verbose classes.</div></div></blockquote><div><br class=3D""></div><div>Y=
es, but what problem domain?</div><div><br class=3D""></div><div>We=E2=80=
=99re just speculating, there=E2=80=99s no need to toy with an implementati=
on.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"lt=
r" style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D""><div class=3D"">For a totally fantastical =
and implausible example,</div></div></blockquote><div><br class=3D""></div>=
<div>But why? It=E2=80=99s not really productive to make suggestions just b=
ecause they look weird.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D"prettypr=
int" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; =
background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">template</span>=
<span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&lt;<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">a=
uto</span>&nbsp;<span class=3D"styled-by-prettify" style=3D"color: rgb(102,=
 0, 102);">TypePred</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">,</span>&nbsp;<span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 136);">typename</span><span class=3D"Apple-converted-s=
pace">&nbsp;</span>T<span class=3D"styled-by-prettify" style=3D"color: rgb(=
102, 102, 0);">&gt;</span><br class=3D"">enable_if_t<span class=3D"styled-b=
y-prettify" style=3D"color: rgb(102, 102, 0);">&lt;</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(102, 0, 102);">TypePred</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&lt;</span>T=
<span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&gt;,=
</span><span class=3D"Apple-converted-space">&nbsp;</span>T<span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(102, 102, 0);">&gt;</span><span clas=
s=3D"Apple-converted-space">&nbsp;</span>enabled_when<span class=3D"styled-=
by-prettify" style=3D"color: rgb(102, 102, 0);">(</span>T t<span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(102, 102, 0);">)</span>&nbsp;<span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span>&nbs=
p;<span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">...=
</span>&nbsp;<span class=3D"styled-by-prettify" style=3D"color: rgb(102, 10=
2, 0);">};</span><br class=3D""></code></div></div></blockquote><div><br cl=
ass=3D""></div><div>The gain in this example is to replace <font face=3D"Co=
urier" class=3D"">template&lt; typename &gt; class</font> with <font face=
=3D"Courier" class=3D"">auto</font>. But that=E2=80=99s not compatible with=
 the proposal at hand.</div><div><br class=3D""></div><div>Adding variable =
template template parameters would only allow replacing&nbsp;<span style=3D=
"font-family: Courier;" class=3D"">template&lt; typename &gt;</span><span s=
tyle=3D"font-family: Courier;" class=3D"">&nbsp;</span><font face=3D"Courie=
r" class=3D"">class</font> with&nbsp;<span style=3D"font-family: Courier;" =
class=3D"">template&lt; typename &gt;</span><span style=3D"font-family: Cou=
rier;" class=3D"">&nbsp;</span><font face=3D"Courier" class=3D"">bool</font=
>, and that=E2=80=99s not much of a gain at all. Fortunately, template temp=
late parameters are very seldom needed.</div><div><br class=3D""></div><div=
>The difference in verboseness between a class and a variable template is a=
lso modest, in case you might ever need the class template.</div><div><br c=
lass=3D""></div><div><span class=3D"styled-by-prettify" style=3D"font-famil=
y: monospace; color: rgb(0, 0, 136);">template</span><span class=3D"styled-=
by-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0);">&lt=
;</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace;=
 color: rgb(0, 0, 136);">typename</span><span class=3D"styled-by-prettify" =
style=3D"font-family: monospace;">&nbsp;T</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: monospace; color: rgb(102, 102, 0);">&gt;</sp=
an><span class=3D"styled-by-prettify" style=3D"font-family: monospace;"><br=
 class=3D""></span><span class=3D"styled-by-prettify" style=3D"font-family:=
 monospace; color: rgb(0, 0, 136);">constexpr</span><span class=3D"styled-b=
y-prettify" style=3D"font-family: monospace;">&nbsp;</span><span class=3D"s=
tyled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, 136);"=
>bool</span><span class=3D"styled-by-prettify" style=3D"font-family: monosp=
ace;">&nbsp;isInt&nbsp;</span><span class=3D"styled-by-prettify" style=3D"f=
ont-family: monospace; color: rgb(102, 102, 0);">=3D</span><span class=3D"s=
tyled-by-prettify" style=3D"font-family: monospace;">&nbsp;std</span><span =
class=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(10=
2, 102, 0);">::</span><span class=3D"styled-by-prettify" style=3D"font-fami=
ly: monospace;">is_same_v</span><span class=3D"styled-by-prettify" style=3D=
"font-family: monospace; color: rgb(102, 102, 0);">&lt;</span><span class=
=3D"styled-by-prettify" style=3D"font-family: monospace;">T</span><span cla=
ss=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(102, =
102, 0);">,</span><span class=3D"styled-by-prettify" style=3D"font-family: =
monospace;">&nbsp;</span><span class=3D"styled-by-prettify" style=3D"font-f=
amily: monospace; color: rgb(0, 0, 136);">int</span><span class=3D"styled-b=
y-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0);">&gt;=
;</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace;=
"><br class=3D""></span></div><div><span class=3D"styled-by-prettify" style=
=3D"font-family: monospace; color: rgb(102, 102, 0);"><br class=3D""></span=
></div><div><span class=3D"styled-by-prettify" style=3D"font-family: monosp=
ace; color: rgb(0, 0, 136);">template</span><span class=3D"styled-by-pretti=
fy" style=3D"font-family: monospace; color: rgb(102, 102, 0);">&lt;</span><=
span class=3D"styled-by-prettify" style=3D"font-family: monospace; color: r=
gb(0, 0, 136);">typename</span><span class=3D"styled-by-prettify" style=3D"=
font-family: monospace;">&nbsp;T</span><span class=3D"styled-by-prettify" s=
tyle=3D"font-family: monospace; color: rgb(102, 102, 0);">&gt;</span><span =
class=3D"styled-by-prettify" style=3D"font-family: monospace;"><br class=3D=
""></span><span class=3D"styled-by-prettify" style=3D"font-family: monospac=
e;"><font color=3D"#000088" class=3D"">struct</font>&nbsp;isInt&nbsp;</span=
><span class=3D"styled-by-prettify" style=3D"font-family: monospace; color:=
 rgb(102, 102, 0);">:</span><span class=3D"styled-by-prettify" style=3D"fon=
t-family: monospace;">&nbsp;std</span><span class=3D"styled-by-prettify" st=
yle=3D"font-family: monospace; color: rgb(102, 102, 0);">::</span><span cla=
ss=3D"styled-by-prettify" style=3D"font-family: monospace;">integral_consta=
nt</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace=
; color: rgb(102, 102, 0);">&lt;&nbsp;</span><span class=3D"styled-by-prett=
ify" style=3D"font-family: monospace;">bool</span><span class=3D"styled-by-=
prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0);">,</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: monospace;">&nbs=
p;</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace=
; color: rgb(102, 102, 0);"><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);">std</span><span class=3D"styled-by-prettify">::</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">is_same_v</=
span><span class=3D"styled-by-prettify">&lt;</span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(0, 0, 0);">T</span><span class=3D"styled-by-=
prettify">,</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0,=
 0, 0);">&nbsp;</span><span class=3D"styled-by-prettify" style=3D"color: rg=
b(0, 0, 136);">int</span><span class=3D"styled-by-prettify">&gt;&nbsp;</spa=
n>&gt;;</span></div></div></body></html>

<p></p>

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

--Apple-Mail=_3B5C566A-C136-443A-B8CB-48D36B970C0D--

.

On 13 January 2015 at 22:23, David Krauss <potswa@gmail.com> wrote:
> The difference in verboseness between a class and a variable template is
> also modest, in case you might ever need the class template.
>
> template<typename T>
> constexpr bool isInt = std::is_same_v<T, int>;
>
> template<typename T>
> struct isInt : std::integral_constant< bool, std::is_same_v<T, int> >;


Are you perhaps trying to make the case for the variable template? The
difference
in verboseness seems to be sufficient that the above "class template" of yours
is ill-formed. :P

--

---
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 2015=E2=80=9301=E2=80=9314, at 4:27 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 13 January 2015 at 22:23, David Krauss <potswa@gmail.com> wrote:
>> template<typename T>
>> struct isInt : std::integral_constant< bool, std::is_same_v<T, int> >;
>=20
>=20
> Are you perhaps trying to make the case for the variable template? The
> difference
> in verboseness seems to be sufficient that the above "class template" of =
yours
> is ill-formed. :P

Fine, 2-3 more characters for the braces=E2=80=A6 it=E2=80=99s 4:30 AM here=
, no coffee yet.

Anyone messing with template template parameters should be more than capabl=
e of writing a class. Perhaps lambdas or expression alias semantics could m=
ake it easier to pass a compile-time expression into a template. But the pr=
oblem pretty much never comes up, which is why I=E2=80=99m trying to tease =
a use-case from Scott.

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

.

------=_Part_875_342995078.1421184618220
Content-Type: multipart/alternative;
 boundary="----=_Part_876_872167398.1421184618220"

------=_Part_876_872167398.1421184618220
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I can't think of a specific use-case, but if I have a type-dependent=20
predicate defines as a variable template, then I can't use it as a template=
=20
parameter which makes them useless in template meta-programming, despite=20
being the most convenient way of defining type-dependent predicates. I=20
don't mind appending `::value` to a type, but I very much mind the verbose=
=20
syntax of defining and specializing new types. If it were not for this, I=
=20
would prefer variable templates to class templates.

On Tuesday, January 13, 2015 at 3:34:27 PM UTC-5, David Krauss wrote:
>
>
> > On 2015=E2=80=9301=E2=80=9314, at 4:27 AM, Ville Voutilainen <ville.vo.=
...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > On 13 January 2015 at 22:23, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:=20
> >> template<typename T>=20
> >> struct isInt : std::integral_constant< bool, std::is_same_v<T, int> >;=
=20
> >=20
> >=20
> > Are you perhaps trying to make the case for the variable template? The=
=20
> > difference=20
> > in verboseness seems to be sufficient that the above "class template" o=
f=20
> yours=20
> > is ill-formed. :P=20
>
> Fine, 2-3 more characters for the braces=E2=80=A6 it=E2=80=99s 4:30 AM he=
re, no coffee=20
> yet.=20
>
> Anyone messing with template template parameters should be more than=20
> capable of writing a class. Perhaps lambdas or expression alias semantics=
=20
> could make it easier to pass a compile-time expression into a template. B=
ut=20
> the problem pretty much never comes up, which is why I=E2=80=99m trying t=
o tease a=20
> use-case from Scott.

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

------=_Part_876_872167398.1421184618220
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I can't think of a specific use-case, but if I have a type=
-dependent predicate defines as a variable template, then I can't use it as=
 a template parameter which makes them useless in template meta-programming=
, despite being the most convenient way of defining type-dependent predicat=
es. I don't mind appending `::value` to a type, but I very much mind the ve=
rbose syntax of defining and specializing new types. If it were not for thi=
s, I would prefer variable templates to class templates.<br><br>On Tuesday,=
 January 13, 2015 at 3:34:27 PM UTC-5, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>&gt; On 2015=E2=80=9301=E2=80=9314, at 4:27 AM, Ville Voutilainen &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"UyJMhz2E8=
4sJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; On 13 January 2015 at 22:23, David Krauss &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"UyJMhz2E84sJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; template&lt;typename T&gt;
<br>&gt;&gt; struct isInt : std::integral_constant&lt; bool, std::is_same_v=
&lt;T, int&gt; &gt;;
<br>&gt;=20
<br>&gt;=20
<br>&gt; Are you perhaps trying to make the case for the variable template?=
 The
<br>&gt; difference
<br>&gt; in verboseness seems to be sufficient that the above "class templa=
te" of yours
<br>&gt; is ill-formed. :P
<br>
<br>Fine, 2-3 more characters for the braces=E2=80=A6 it=E2=80=99s 4:30 AM =
here, no coffee yet.
<br>
<br>Anyone messing with template template parameters should be more than ca=
pable of writing a class. Perhaps lambdas or expression alias semantics cou=
ld make it easier to pass a compile-time expression into a template. But th=
e problem pretty much never comes up, which is why I=E2=80=99m trying to te=
ase a use-case from Scott.</blockquote></div>

<p></p>

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

------=_Part_876_872167398.1421184618220--
------=_Part_875_342995078.1421184618220--

.

--Apple-Mail=_03A868C3-4514-4A41-BD4E-C140230C1AD5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9314, at 5:30 AM, Scott Prager <splinterofchaos@=
gmail.com> wrote:
>=20
> I can't think of a specific use-case, but if I have a type-dependent pred=
icate defines as a variable template, then I can't use it as a template par=
ameter which makes them useless in template meta-programming

Huh? When do you ever pass a predicate (or other metafunction) as a templat=
e template parameter? You seem to imply that this is essential to metaprogr=
amming, but I don=E2=80=99t recall encountering it at all. This seems centr=
al to your argument, so there should be at least one example. (Not necessar=
ily code, but just some anecdote, problem description, or citation.)

> despite being the most convenient way of defining type-dependent predicat=
es.


Compound predicates, defined in terms of a single Boolean expression, may b=
e initially defined as variable templates. Anything that requires deduction=
 or specialization still must be defined as a class template; only then can=
 a variable template alias it.

Overloading and partial specialization were omitted from variable templates=
 on purpose.

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

--Apple-Mail=_03A868C3-4514-4A41-BD4E-C140230C1AD5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9314, at 5:30 AM, Scott Prager &lt;<a href=3D"mailto:splinterofchaos=
@gmail.com" class=3D"">splinterofchaos@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; f=
loat: none; display: inline !important;" class=3D"">I can't think of a spec=
ific use-case, but if I have a type-dependent predicate defines as a variab=
le template, then I can't use it as a template parameter which makes them u=
seless in template meta-programming</span></div></blockquote></div><br clas=
s=3D""><div class=3D"">Huh? When do you ever pass a predicate (or other met=
afunction) as a template template parameter? You seem to imply that this is=
 essential to metaprogramming, but I don=E2=80=99t recall encountering it a=
t all. This seems central to your argument, so there should be at least one=
 example. (Not necessarily code, but just some anecdote, problem descriptio=
n, or citation.)</div><div class=3D""><br class=3D""></div><div class=3D"">=
<blockquote type=3D"cite" class=3D""><span class=3D"" style=3D"display: inl=
ine !important;">despite being the most convenient way of defining type-dep=
endent predicates.</span></blockquote></div><div class=3D""><span class=3D"=
" style=3D"display: inline !important;"><br class=3D""></span></div><div cl=
ass=3D""><span class=3D"" style=3D"display: inline !important;">Compound pr=
edicates, defined in terms of a single Boolean expression, may be initially=
 defined as variable templates. Anything that requires deduction or special=
ization still must be defined as a class template; only then can a variable=
 template alias it.</span></div><div class=3D""><span class=3D"" style=3D"d=
isplay: inline !important;"><br class=3D""></span></div><div class=3D""><sp=
an class=3D"" style=3D"display: inline !important;">Overloading and partial=
 specialization were omitted from variable templates on purpose.</span></di=
v></body></html>

<p></p>

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

--Apple-Mail=_03A868C3-4514-4A41-BD4E-C140230C1AD5--

.

On 13 January 2015 at 23:52, David Krauss <potswa@gmail.com> wrote:
> Overloading and partial specialization were omitted from variable templates
> on purpose.


So on purpose, that they allow partial specialization?

--

---
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 2015=E2=80=9301=E2=80=9314, at 5:59 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 13 January 2015 at 23:52, David Krauss <potswa@gmail.com> wrote:
>> Overloading and partial specialization were omitted from variable templa=
tes
>> on purpose.
>=20
> So on purpose, that they allow partial specialization?

Do they? The specification of VTs is scattered and incomplete, but I don=E2=
=80=99t see where the C++14 IS specifies or implies it. Partial specializat=
ion is defined in a section entitled =E2=80=9CClass template partial specia=
lizations,=E2=80=9D which quite often restricts itself to class templates.

I can find only a tangential reference to variable template partial special=
izations, in =C2=A714.3.3/2, which says that variable template template par=
ameters may refer to partial specializations. This is clearly in error sinc=
e we don=E2=80=99t have variable template template parameters.

As far as I know, Clang implemented variable template partial specializatio=
ns taking Gaby=E2=80=99s word on good faith, but it=E2=80=99s not actually =
in the standard. Perhaps a DR will add the normative text, if that=E2=80=99=
s really the consensus.

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

.

On 14 January 2015 at 00:24, David Krauss <potswa@gmail.com> wrote:
>> So on purpose, that they allow partial specialization?
> Do they? The specification of VTs is scattered and incomplete, but I don=
=E2=80=99t see where the C++14 IS

Yes, they do. That was always the design intent.

> As far as I know, Clang implemented variable template partial specializat=
ions taking Gaby=E2=80=99s word on

gcc implements variable template partial specializations as well.

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

.

> On 2015=E2=80=9301=E2=80=9314, at 6:25 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 14 January 2015 at 00:24, David Krauss <potswa@gmail.com> wrote:
>>> So on purpose, that they allow partial specialization?
>> Do they? The specification of VTs is scattered and incomplete, but I don=
=E2=80=99t see where the C++14 IS
>=20
> Yes, they do. That was always the design intent.

Digging deeper, so far, the specification has only got as far as DR 1711, w=
hich is in the drafting stage with no proposed resolution.

I might be wrong that the omission is on purpose, but so far it=E2=80=99s a=
 stretch to say that C++14 officially supports this.

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

.

--001a11c3380e6e62a5050c9132ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 13, 2015 at 11:00 AM, Scott Prager <splinterofchaos@gmail.com>
wrote:
> On Monday, January 12, 2015 at 9:25:33 PM UTC-5, David Krauss wrote:
>> On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager <splinte...@gmai=
l.com> wrote:
>>
>>> A little off-topic in this thread, but being able to pass a variable
>>> template as a parameter when the type parameter is unknown would be
nice. It
>>> would make them much more useful in template meta-programming.
>>
>> Is there a real use-case? Variable templates are a convenience, but
>> they=E2=80=99re not primitive. You can emulate them with class-based
metafunctions.
>> Passing a variable template as a metafunction likewise only requires a
>> wrapper class.
>
> I'm not quite sure because I haven't toyed with them much, but I'd like t=
o
> see a C++ where template meta-programming is possible using only `using`
and
> variable templates. That is, without creating overly verbose classes.
>
> For a totally fantastical and implausible example,
>
> template<bool Pred=3Dfalse, typename T=3Dvoid> using enable_if_t;
>
> template<typename T> using enable_if_t<true, T> =3D T;
>
> template<typename T> constexpr bool isInt =3D std::is_same_v<T, int>;
>
> template<auto TypePred, typename T>
> enable_if_t<TypePred<T>, T> enabled_when(T t) { ... };
>
> auto x =3D enabled_when<isInt>(...);
>
> Though it's rather difficult to imagine what the syntax would look like
> without abusing `auto`. Not even sure if I'll find much use for variable
> templates by the time mainline gcc supports them.

No need to self-deprecate with "totally fantastical and implausible."
Variable templates are coming even in the C++14 standard library; it's not
fantastic to imagine that someone might want to write generic code using
them. But let's simplify your example code by taking an existing
single-argument template:

    #include <type_traits>  // std::is_integral, std::is_integral_v

    #ifdef WORKS_IN_CXX14

    template<template<typename...> class Pred, typename T, typename Enable
=3D void> T enable_if(T t);
    template<template<typename...> class Pred, typename T,
std::enable_if_t<Pred<T>::value>> T enable_if(T t) { return t; }

    auto x =3D enable_if<std::is_integral>(1);  // accepted
    auto y =3D enable_if<std::is_integral>(1.0);  // rejected

    #else

    template<template<typename...> bool Pred, typename T, typename Enable =
=3D
void> T enable_if(T t);
    template<template<typename...> bool Pred, typename T,
std::enable_if_t<Pred<T>>> T enable_if(T t) { return t; }

    auto x =3D enable_if<std::is_integral_v>(1);  // should be accepted
    auto y =3D enable_if<std::is_integral_v>(1.0);  // should be rejected

    #endif

Now, the not-so-fantastical followup scenario is to imagine that somebody
(in the year >2014) implements a traits library, and, because variable
templates exist, decides to implement it "as the standard library SHOULD
have been implemented", without all these ::value and ::type hacks. So he
implements

    template<typename T> bool is_foo =3D ...;  // STL would call this
"is_foo_v"

Now, if I want to define the "enable_if()" kind of function template for
use with this library, I have to manually wrap "is_foo" in a dummy class
with a ::value member, just to get my code to compile. This is dumb!

    template<typename T> class is_foo_wrapper {
        static constexpr bool value =3D is_foo<T>;
    };

    auto x =3D enable_if<is_foo_wrapper>(1);

So I find myself repeating this "dummy class with ::value member" pattern
for every variable template I want to use. As a good programmer, I'm
trained to identify redundancy and eliminate it, so I try to factor out
this redundancy into a class template wrapper<Pred>... but I can't, because
I can't pass variable templates as template parameters! And so I'm trapped,
unable to implement the proper abstraction.

This is not a fantastical, obscure, implausible use-case. This is exactly
the state of the art towards which the Standard is moving, as of C++14.

=E2=80=93Arthur






>
>>
>>
>> Applying this solution to the previous (unrealistic) example,
>>
>> template<typename T> T pi =3D static_cast<T>(3.14);
>>
>> template< typename T >
>> struct pi_as_metafunction {
>>     static T const & value =3D pi< T >;
>> };
>>
>> template<template<typename T> class P> int int_plus_one =3D P<int>::valu=
e +
>> 1;
>>
>> int main()
>> {
>>     return int_plus_one<pi_as_metafunction>;  // which is pi<int> + 1,
>> which is 4
>> }
>>
>> What this doesn=E2=80=99t support is partial specialization, i.e. recove=
ring the
>> int parameter from pi<int>. However, is that something we really want? I=
t
>> would support such abuse as,
>>
>> template< int const & obj >
>> struct is_typename_parameterized : std::false_type {};
>>
>> template< template< typename type > int const & templ, typename param >
>> struct is_typename_parameterized< templ< param > > : std::true_type {};
>>
>> int x;
>> constexpr int const * nums[] =3D { & x, & pi< int > };
>>
>> static_assert( ! is_typename_parameterized< * nums[0] >();
>> static_assert( is_typename_parameterized< * nums[1] >();
>>
>> Having the computed address of a variable template specialization behave
>> differently from the template-id of the specialization would introduce
yet
>> another kind of expression: more complicated rules to support corner
cases
>> of more arcane syntax.
>>
>> Metaprogramming is complicated enough using the identities and propertie=
s
>> of types. Sending different variables into different templates is
madness,
>> and not something to be made more convenient. (It is already possible to
do
>> this sort of thing using SFINAE and wrapper classes, so we=E2=80=99re no=
t even
>> talking about added capability.)
>>
>> Likewise, we=E2=80=99ve had function templates for a long time, but nobo=
dy ever
>> wishes for template parameters that are unspecialized function templates=
..
>>
>> The C++ template system is the last place we should be pursuing solution=
s
>> in search of a problem.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
>
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc/un=
subscribe
..
> To unsubscribe from this group and all its topics, 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/.

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

<div dir=3D"ltr">On Tue, Jan 13, 2015 at 11:00 AM, Scott Prager &lt;<a href=
=3D"mailto:splinterofchaos@gmail.com">splinterofchaos@gmail.com</a>&gt; wro=
te:<br>&gt; On Monday, January 12, 2015 at 9:25:33 PM UTC-5, David Krauss w=
rote:<br>&gt;&gt; On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager &=
lt;<a href=3D"mailto:splinte...@gmail.com">splinte...@gmail.com</a>&gt; wro=
te:<br>&gt;&gt;<br>&gt;&gt;&gt; A little off-topic in this thread, but bein=
g able to pass a variable<br>&gt;&gt;&gt; template as a parameter when the =
type parameter is unknown would be nice. It<br>&gt;&gt;&gt; would make them=
 much more useful in template meta-programming.<br>&gt;&gt;<br>&gt;&gt; Is =
there a real use-case? Variable templates are a convenience, but<br>&gt;&gt=
; they=E2=80=99re not primitive. You can emulate them with class-based meta=
functions.<br>&gt;&gt; Passing a variable template as a metafunction likewi=
se only requires a<br>&gt;&gt; wrapper class.<br>&gt;<br>&gt; I&#39;m not q=
uite sure because I haven&#39;t toyed with them much, but I&#39;d like to<b=
r>&gt; see a C++ where template meta-programming is possible using only `us=
ing` and<br>&gt; variable templates. That is, without creating overly verbo=
se classes.<br>&gt;<br>&gt; For a totally fantastical and implausible examp=
le,<br>&gt;<br>&gt; template&lt;bool Pred=3Dfalse, typename T=3Dvoid&gt; us=
ing enable_if_t;<br>&gt;<br>&gt; template&lt;typename T&gt; using enable_if=
_t&lt;true, T&gt; =3D T;<br>&gt;<br>&gt; template&lt;typename T&gt; constex=
pr bool isInt =3D std::is_same_v&lt;T, int&gt;;<br>&gt;<br>&gt; template&lt=
;auto TypePred, typename T&gt;<br>&gt; enable_if_t&lt;TypePred&lt;T&gt;, T&=
gt; enabled_when(T t) { ... };<br>&gt;<br>&gt; auto x =3D enabled_when&lt;i=
sInt&gt;(...);<br>&gt;<br>&gt; Though it&#39;s rather difficult to imagine =
what the syntax would look like<br>&gt; without abusing `auto`. Not even su=
re if I&#39;ll find much use for variable<br>&gt; templates by the time mai=
nline gcc supports them.<br><br>No need to self-deprecate with &quot;totall=
y fantastical and implausible.&quot; Variable templates are coming even in =
the C++14 standard library; it&#39;s not fantastic to imagine that someone =
might want to write generic code using them. But let&#39;s simplify your ex=
ample code by taking an existing single-argument template:<br><br><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 #include &lt;type_traits&gt; =
=C2=A0// std::is_integral, std::is_integral_v</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 =C2=A0 #ifdef WORKS_IN_CXX14</font></div><div><font face=3D=
"monospace, monospace"><br></font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 template&lt;template&lt;typename...&gt; class Pred, typ=
ename T, typename Enable =3D void&gt; T enable_if(T t);</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;template&lt;typ=
ename...&gt; class Pred, typename T, std::enable_if_t&lt;Pred&lt;T&gt;::val=
ue&gt;&gt; T enable_if(T t) { return t; }</font></div><div><font face=3D"mo=
nospace, monospace"><br></font></div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 auto x =3D enable_if&lt;std::is_integral&gt;(1); =C2=A0// =
accepted</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 auto y =3D enable_if&lt;std::is_integral&gt;(1.0); =C2=A0// rejected</font=
></div><div><font face=3D"monospace, monospace"><br></font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 #else</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 template&lt;template&lt;typename...&gt; bool Pred=
, typename T, typename Enable =3D void&gt; T enable_if(T t);</font></div><d=
iv><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;template&l=
t;typename...&gt; bool Pred, typename T, std::enable_if_t&lt;Pred&lt;T&gt;&=
gt;&gt; T enable_if(T t) { return t; }</font></div><div><font face=3D"monos=
pace, monospace"><br></font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 auto x =3D enable_if&lt;std::is_integral_v&gt;(1); =C2=A0// s=
hould be accepted</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 auto y =3D enable_if&lt;std::is_integral_v&gt;(1.0); =C2=A0// sh=
ould be rejected</font></div><div><font face=3D"monospace, monospace"><br><=
/font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 #endif</=
font></div><br>Now, the not-so-fantastical followup scenario is to imagine =
that somebody (in the year &gt;2014) implements a traits library, and, beca=
use variable templates exist, decides to implement it &quot;as the standard=
 library SHOULD have been implemented&quot;, without all these ::value and =
::type hacks. So he implements<div><br></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 template&lt;typename T&gt; bool is_foo =3D ...; =
=C2=A0// STL would call this &quot;is_foo_v&quot;</font></div><div><br></di=
v><div>Now, if I want to define the &quot;enable_if()&quot; kind of functio=
n template for use with this library, I have to manually wrap &quot;is_foo&=
quot; in a dummy class with a ::value member, just to get my code to compil=
e. This is dumb!</div><div><br></div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 template&lt;typename T&gt; class is_foo_wrapper {</font></=
div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 st=
atic constexpr bool value =3D is_foo&lt;T&gt;;</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 };</font></div><div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 =C2=A0 auto x =3D enable_if&lt;is_foo_wrapper&gt;(1);</font=
></div></div><div><font face=3D"monospace, monospace"><br></font></div><div=
>So I find myself repeating this &quot;dummy class with <font face=3D"monos=
pace, monospace">::value</font> member&quot; pattern for every variable tem=
plate I want to use. As a good programmer, I&#39;m trained to identify redu=
ndancy and eliminate it, so I try to factor out this redundancy into a clas=
s template <font face=3D"monospace, monospace">wrapper&lt;Pred&gt;</font>..=
.. but I can&#39;t, because I can&#39;t pass variable templates as template =
parameters! And so I&#39;m trapped, unable to implement the proper abstract=
ion.</div><div><br></div><div>This is not a fantastical, obscure, implausib=
le use-case. This is exactly the state of the art towards which the Standar=
d is moving, as of C++14.</div><div><br></div><div>=E2=80=93Arthur</div><di=
v><br></div><div><br></div><div><br></div><div><br><br><br>&gt; =C2=A0<br>&=
gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Applying this solution to the previous (unr=
ealistic) example,<br>&gt;&gt;<br>&gt;&gt; template&lt;typename T&gt; T pi =
=3D static_cast&lt;T&gt;(3.14);<br>&gt;&gt;<br>&gt;&gt; template&lt; typena=
me T &gt;<br>&gt;&gt; struct pi_as_metafunction {<br>&gt;&gt; =C2=A0 =C2=A0=
 static T const &amp; value =3D pi&lt; T &gt;;<br>&gt;&gt; };<br>&gt;&gt;<b=
r>&gt;&gt; template&lt;template&lt;typename T&gt; class P&gt; int int_plus_=
one =3D P&lt;int&gt;::value +<br>&gt;&gt; 1;<br>&gt;&gt;<br>&gt;&gt; int ma=
in()<br>&gt;&gt; {<br>&gt;&gt; =C2=A0 =C2=A0 return int_plus_one&lt;pi_as_m=
etafunction&gt;; =C2=A0// which is pi&lt;int&gt; + 1,<br>&gt;&gt; which is =
4<br>&gt;&gt; }<br>&gt;&gt;<br>&gt;&gt; What this doesn=E2=80=99t support i=
s partial specialization, i.e. recovering the<br>&gt;&gt; int parameter fro=
m pi&lt;int&gt;. However, is that something we really want? It<br>&gt;&gt; =
would support such abuse as,<br>&gt;&gt;<br>&gt;&gt; template&lt; int const=
 &amp; obj &gt;<br>&gt;&gt; struct is_typename_parameterized : std::false_t=
ype {};<br>&gt;&gt;<br>&gt;&gt; template&lt; template&lt; typename type &gt=
; int const &amp; templ, typename param &gt;<br>&gt;&gt; struct is_typename=
_parameterized&lt; templ&lt; param &gt; &gt; : std::true_type {};<br>&gt;&g=
t;<br>&gt;&gt; int x;<br>&gt;&gt; constexpr int const * nums[] =3D { &amp; =
x, &amp; pi&lt; int &gt; };<br>&gt;&gt;<br>&gt;&gt; static_assert( ! is_typ=
ename_parameterized&lt; * nums[0] &gt;();<br>&gt;&gt; static_assert( is_typ=
ename_parameterized&lt; * nums[1] &gt;();<br>&gt;&gt;<br>&gt;&gt; Having th=
e computed address of a variable template specialization behave<br>&gt;&gt;=
 differently from the template-id of the specialization would introduce yet=
<br>&gt;&gt; another kind of expression: more complicated rules to support =
corner cases<br>&gt;&gt; of more arcane syntax.<br>&gt;&gt;<br>&gt;&gt; Met=
aprogramming is complicated enough using the identities and properties<br>&=
gt;&gt; of types. Sending different variables into different templates is m=
adness,<br>&gt;&gt; and not something to be made more convenient. (It is al=
ready possible to do<br>&gt;&gt; this sort of thing using SFINAE and wrappe=
r classes, so we=E2=80=99re not even<br>&gt;&gt; talking about added capabi=
lity.)<br>&gt;&gt;<br>&gt;&gt; Likewise, we=E2=80=99ve had function templat=
es for a long time, but nobody ever<br>&gt;&gt; wishes for template paramet=
ers that are unspecialized function templates.<br>&gt;&gt;<br>&gt;&gt; The =
C++ template system is the last place we should be pursuing solutions<br>&g=
t;&gt; in search of a problem.<br>&gt;<br>&gt; --<br>&gt;<br>&gt; ---<br>&g=
t; You received this message because you are subscribed to a topic in the<b=
r>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.=
<br>&gt; To unsubscribe from this topic, visit<br>&gt; <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc/unsubscribe=
">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cqaS7PcU5Qc/=
unsubscribe</a>.<br>&gt; To unsubscribe from this group and all its topics,=
 send an email to<br>&gt; <a href=3D"mailto:std-proposals%2Bunsubscribe@iso=
cpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>&gt; To post to this =
group, send email to <a href=3D"mailto:std-proposals@isocpp.org">std-propos=
als@isocpp.org</a>.<br>&gt; Visit this group at<br>&gt; <a href=3D"http://g=
roups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.co=
m/a/isocpp.org/group/std-proposals/</a>.</div></div>

<p></p>

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

--001a11c3380e6e62a5050c9132ed--

.

--Apple-Mail=_ED8C9708-919D-4220-A252-F672E11ED4F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9314, at 7:43 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> No need to self-deprecate with "totally fantastical and implausible." Var=
iable templates are coming even in the C++14 standard library; it's not fan=
tastic to imagine that someone might want to write generic code using them.=
 But let's simplify your example code by taking an existing single-argument=
 template:
>=20
>     #include <type_traits>  // std::is_integral, std::is_integral_v
>=20
>     #ifdef WORKS_IN_CXX14
>=20
>     template<template<typename...> class Pred, typename T, typename Enabl=
e =3D void> T enable_if(T t);
>     template<template<typename...> class Pred, typename T, std::enable_if=
_t<Pred<T>::value>> T enable_if(T t) { return t; }

This looks like it=E2=80=99s supposed to be a function template partial spe=
cialization. Also, the name enable_if is very confusing for a function. It =
looks like you meant,

template< template< typename ... > class Pred, typename Type >
constexpr std::enable_if_t< Pred< Type >::value >, Type >
value_if( Type value ) { return value; }

This is similar to Scott=E2=80=99s example. Again, is it plausible? Does it=
 connect to the real world?

The potential for this sort of thing has always existed. Nothing in C++11 o=
nward makes it more likely to happen, if it=E2=80=99s never happened before=
..

For what it=E2=80=99s worth, I prefer to pass templates inside wrapper clas=
ses instead of by template template parameters. The template template param=
eter syntax is over-specific and noisy.

template< typename ... >
struct thing { mem bers; };

template< typename, typename =3D void >
struct metafunction : std::false_type {};

struct some_traits {
    template< typename ... >
    using state =3D thing;

    template< typename ... >
    using trait =3D metafunction;
};

// Look ma, no template template parameter!
template< typename type, typename traits =3D default_traits< type > >
class specialized {
    typename traits::template state< specialized, int > member;
    =E2=80=A6
};

specialized< int, some_traits > object;

I=E2=80=99ve seen cases like this, but I=E2=80=99ve never seen a parameteri=
zation over predicates.

If there=E2=80=99s one thing in there that needs work, it=E2=80=99s the bus=
ywork of putting the typename and template keywords everywhere. That=E2=80=
=99s where committee effort should go.

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

--Apple-Mail=_ED8C9708-919D-4220-A252-F672E11ED4F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9314, at 7:43 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D"">No need to self-deprecate with "totally fantastica=
l and implausible." Variable templates are coming even in the C++14 standar=
d library; it's not fantastic to imagine that someone might want to write g=
eneric code using them. But let's simplify your example code by taking an e=
xisting single-argument template:<br class=3D""><br class=3D""><div class=
=3D""><font face=3D"monospace, monospace" class=3D"">&nbsp; &nbsp; #include=
 &lt;type_traits&gt; &nbsp;// std::is_integral, std::is_integral_v</font></=
div><div class=3D""><font face=3D"monospace, monospace" class=3D""><br clas=
s=3D""></font></div><div class=3D""><font face=3D"monospace, monospace" cla=
ss=3D"">&nbsp; &nbsp; #ifdef WORKS_IN_CXX14</font></div><div class=3D""><fo=
nt face=3D"monospace, monospace" class=3D""><br class=3D""></font></div><di=
v class=3D""><font face=3D"monospace, monospace" class=3D"">&nbsp; &nbsp; t=
emplate&lt;template&lt;typename...&gt; class Pred, typename T, typename Ena=
ble =3D void&gt; T enable_if(T t);</font></div><div class=3D""><font face=
=3D"monospace, monospace" class=3D"">&nbsp; &nbsp; template&lt;template&lt;=
typename...&gt; class Pred, typename T, std::enable_if_t&lt;Pred&lt;T&gt;::=
value&gt;&gt; T enable_if(T t) { return t; }</font></div></div></div></bloc=
kquote><div><br class=3D""></div><div>This looks like it=E2=80=99s supposed=
 to be a function template partial specialization. Also, the name <font fac=
e=3D"Courier" class=3D"">enable_if</font> is very confusing for a function.=
 It looks like you meant,</div><div><br class=3D""></div><div><font face=3D=
"Courier" class=3D"">template&lt; template&lt; typename ... &gt; class Pred=
, typename Type &gt;</font></div><div><font face=3D"Courier" class=3D"">con=
stexpr std::enable_if_t&lt; Pred&lt; Type &gt;::value &gt;, Type &gt;</font=
></div><div><font face=3D"Courier" class=3D"">value_if( Type value ) { retu=
rn value; }</font></div><div><br class=3D""></div><div>This is similar to S=
cott=E2=80=99s example. Again, is it plausible? Does it connect to the real=
 world?</div><div><br class=3D""></div><div>The potential for this sort of =
thing has always existed. Nothing in C++11 onward makes it more likely to h=
appen, if it=E2=80=99s never happened before.</div><div><br class=3D""></di=
v><div>For what it=E2=80=99s worth, I prefer to pass templates inside wrapp=
er classes instead of by template template parameters. The template templat=
e parameter syntax is over-specific and noisy.</div><div><br class=3D""></d=
iv><div><font face=3D"Courier" class=3D"">template&lt; typename ... &gt;</f=
ont></div><div><font face=3D"Courier" class=3D"">struct thing { mem bers; }=
;</font></div><div><font face=3D"Courier" class=3D""><br class=3D""></font>=
</div><div><div><font face=3D"Courier" class=3D"">template&lt; typename, ty=
pename =3D void &gt;</font></div><div><font face=3D"Courier" class=3D"">str=
uct metafunction : std::false_type {};</font></div><div class=3D""><font fa=
ce=3D"Courier" class=3D""><br class=3D""></font></div></div><div><font face=
=3D"Courier" class=3D"">struct some_traits {</font></div><div><font face=3D=
"Courier" class=3D"">&nbsp; &nbsp; template&lt; typename ... &gt;</font></d=
iv><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; using state =3D thi=
ng;</font></div><font face=3D"Courier" class=3D""><br class=3D""></font><di=
v><font face=3D"Courier" class=3D"">&nbsp; &nbsp; template&lt; typename ...=
 &gt;</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; usin=
g trait =3D metafunction;</font></div><font face=3D"Courier" class=3D"">};<=
/font></div><div><font face=3D"Courier" class=3D""><br class=3D""></font></=
div><div><font face=3D"Courier" class=3D"">// Look ma, no template template=
 parameter!</font></div><div><font face=3D"Courier" class=3D"">template&lt;=
 typename type, typename traits =3D default_traits&lt; type &gt; &gt;</font=
></div><div><font face=3D"Courier" class=3D"">class specialized {</font></d=
iv><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; typename traits::te=
mplate state&lt; specialized, int &gt; member;</font></div><div><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; =E2=80=A6</font></div><div><font face=
=3D"Courier" class=3D"">};</font></div><div><font face=3D"Courier" class=3D=
""><br class=3D""></font></div><div><font face=3D"Courier" class=3D"">speci=
alized&lt; int, some_traits &gt; object;</font></div><div><br class=3D""></=
div><div>I=E2=80=99ve seen cases like this, but I=E2=80=99ve never seen a p=
arameterization over predicates.</div><div><br class=3D""></div><div>If the=
re=E2=80=99s one thing in there that needs work, it=E2=80=99s the busywork =
of putting the <font face=3D"Courier" class=3D"">typename</font> and <font =
face=3D"Courier" class=3D"">template</font> keywords everywhere. That=E2=80=
=99s where committee effort should go.</div></body></html>

<p></p>

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

--Apple-Mail=_ED8C9708-919D-4220-A252-F672E11ED4F2--

.

------=_Part_297_1204487791.1421210836857
Content-Type: multipart/alternative;
 boundary="----=_Part_298_1645446715.1421210836857"

------=_Part_298_1645446715.1421210836857
Content-Type: text/plain; charset=UTF-8

I've updated the proposal with a discussion of N3601.  I'll add in
references and acknowledgments later.

--

---
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_298_1645446715.1421210836857
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I've updated the proposal with a discussion of N3601.&nbsp; I'll add in references and acknowledgments later.<br></div>

<p></p>

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

------=_Part_298_1645446715.1421210836857--
------=_Part_297_1204487791.1421210836857--

.

--001a11c3380e52997a050c97cc2a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 13, 2015 at 4:38 PM, David Krauss <potswa@gmail.com> wrote:

> On 2015=E2=80=9301=E2=80=9314, at 7:43 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com>
> wrote:
>
> No need to self-deprecate with "totally fantastical and implausible."
> Variable templates are coming even in the C++14 standard library; it's no=
t
> fantastic to imagine that someone might want to write generic code using
> them. But let's simplify your example code by taking an existing
> single-argument template:
>
>     #include <type_traits>  // std::is_integral, std::is_integral_v
>
>     #ifdef WORKS_IN_CXX14
>
>     template<template<typename...> class Pred, typename T, typename Enabl=
e
> =3D void> T enable_if(T t);
>     template<template<typename...> class Pred, typename T,
> std::enable_if_t<Pred<T>::value>> T enable_if(T t) { return t; }
>
>
> This looks like it=E2=80=99s supposed to be a function template partial
> specialization. Also, the name enable_if is very confusing for a
> function. It looks like you meant,
>
> template< template< typename ... > class Pred, typename Type >
> constexpr std::enable_if_t< Pred< Type >::value >, Type >
> value_if( Type value ) { return value; }
>
> This is similar to Scott=E2=80=99s example. Again, is it plausible? Does =
it
> connect to the real world?
>

Sure! As you pointed out, function partial specializations aren't yet
supported. I should have written:

    template<template<typename...> class Pred, typename T, typename Enable
=3D std::enable_if_t<Pred<T>::value>>
    T enable_if(T t) { return t; }

but let's rename it:

    template<template<typename...> class Pred, typename T, typename Enable
=3D std::enable_if_t<Pred<T>::value>>
    T value_if(T t) { return t; }



> For what it=E2=80=99s worth, I prefer to pass templates inside wrapper cl=
asses
> instead of by template template parameters. [...]
>

// Look ma, no template template parameter!
> template< typename type, typename traits =3D default_traits< type > >
> class specialized {
>     typename traits::template state< specialized, int > member;
>     =E2=80=A6
> };
>

Right. That's the current workaround for the lack of variable templates in
C++11, the lack of function template partial specialization in C++14, etc.
But that syntax is just *ridiculously* noisy. It would be straightforward
to put all templates on the same footing, now that variable templates and
template aliases (a.k.a. typedef templates) have arrived. There's no reason
to privilege class templates above all other templates, except that that's
the way it was done in 1998.


> I=E2=80=99ve seen cases like this, but I=E2=80=99ve never seen a paramete=
rization over
> predicates.
>

That's because the construct isn't valid C++ today. :D  But make it legal,
and I predict that a lot of new code will happily do away with all these
wrapper classes and instead define only the entities that matter.
The practice of wrapping metaprogramming constructs in wrapper classes
(std::is_integral, etc.) is distinct from the practice of bundling lots of
data together into traits classes (std::allocator_traits,
std::numeric_limits, etc.). IMO, you confused the question a little bit by
naming your "wrapper class" in the above example default_traits, when for
the purposes of this example it's just a wrapper around state, not a bundle
of related information.


> If there=E2=80=99s one thing in there that needs work, it=E2=80=99s the b=
usywork of
> putting the typename and template keywords everywhere. That=E2=80=99s whe=
re
> committee effort should go.
>

C++11 template aliases have already solved that problem for type templates
like state.

// Look ma, no busywork keywords!
template< typename type, template <typename...> class state =3D
default_state< type > >
class specialized {
    state< specialized, int > member;
    =E2=80=A6
};

The remaining problem is that the same feature doesn't work for variable
templates or function templates: it works *only* for class templates and
template aliases. That will change eventually, though. My bet is C++17.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Tue, Jan 13, 2015 at 4:38 PM, David Krauss <span dir=3D=
"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><span c=
lass=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=9301=E2=80=9314, at =
7:43 AM, Arthur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com=
" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br><div>=
<div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12px;font-style:n=
ormal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-hei=
ght:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px">No need to self-deprecate with &quot;totally fant=
astical and implausible.&quot; Variable templates are coming even in the C+=
+14 standard library; it&#39;s not fantastic to imagine that someone might =
want to write generic code using them. But let&#39;s simplify your example =
code by taking an existing single-argument template:<br><br><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 #include &lt;type_traits&gt; =C2=A0=
// std::is_integral, std::is_integral_v</font></div><div><font face=3D"mono=
space, monospace"><br></font></div><div><font face=3D"monospace, monospace"=
>=C2=A0 =C2=A0 #ifdef WORKS_IN_CXX14</font></div><div><font face=3D"monospa=
ce, monospace"><br></font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 template&lt;template&lt;typename...&gt; class Pred, typename =
T, typename Enable =3D void&gt; T enable_if(T t);</font></div><div><font fa=
ce=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;template&lt;typename.=
...&gt; class Pred, typename T, std::enable_if_t&lt;Pred&lt;T&gt;::value&gt;=
&gt; T enable_if(T t) { return t; }</font></div></div></div></blockquote><d=
iv><br></div></span><div>This looks like it=E2=80=99s supposed to be a func=
tion template partial specialization. Also, the name <font face=3D"Courier"=
>enable_if</font> is very confusing for a function. It looks like you meant=
,</div><div><br></div><div><font face=3D"Courier">template&lt; template&lt;=
 typename ... &gt; class Pred, typename Type &gt;</font></div><div><font fa=
ce=3D"Courier">constexpr std::enable_if_t&lt; Pred&lt; Type &gt;::value &gt=
;, Type &gt;</font></div><div><font face=3D"Courier">value_if( Type value )=
 { return value; }</font></div><div><br></div><div>This is similar to Scott=
=E2=80=99s example. Again, is it plausible? Does it connect to the real wor=
ld?</div></div></div></blockquote><div><br></div><div>Sure! As you pointed =
out, function partial specializations aren&#39;t yet supported. I should ha=
ve written:</div><div><br></div><div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 template&lt;template&lt;typename...&gt; class Pred, typena=
me T, typename Enable =3D std::enable_if_t&lt;Pred&lt;T&gt;::value&gt;&gt;<=
/font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 T enable=
_if(T t) { return t; }</font></div><div><br></div></div><div>but let&#39;s =
rename it:</div><div><br></div><div><div><font face=3D"monospace, monospace=
">=C2=A0 =C2=A0 template&lt;template&lt;typename...&gt; class Pred, typenam=
e T, typename Enable =3D std::enable_if_t&lt;Pred&lt;T&gt;::value&gt;&gt;</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 T value_i=
f(T t) { return t; }</font></div><div><br></div></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div style=3D"word-wrap:break-word"><div><div></div><div>For w=
hat it=E2=80=99s worth, I prefer to pass templates inside wrapper classes i=
nstead of by template template parameters. [...]</div></div></div></blockqu=
ote><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><di=
v><font face=3D"Courier">// Look ma, no template template parameter!</font>=
</div><div><font face=3D"Courier">template&lt; typename type, typename trai=
ts =3D default_traits&lt; type &gt; &gt;</font></div><div><font face=3D"Cou=
rier">class specialized {</font></div><div><font face=3D"Courier">=C2=A0 =
=C2=A0 typename traits::template state&lt; specialized, int &gt; member;</f=
ont></div><div><font face=3D"Courier">=C2=A0 =C2=A0 =E2=80=A6</font></div><=
div><font face=3D"Courier">};</font></div></div></blockquote><div><br></div=
><div>Right. That&#39;s the current workaround for the lack of variable tem=
plates in C++11, the lack of function template partial specialization in C+=
+14, etc. But that syntax is just *ridiculously* noisy. It would be straigh=
tforward to put all templates on the same footing, now that variable templa=
tes and template aliases (a.k.a. typedef templates) have arrived. There&#39=
;s no reason to privilege class templates above all other templates, except=
 that that&#39;s the way it was done in 1998.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div style=3D"word-wrap:break-word"><div><font face=3D"Courier"><=
/font></div><div>I=E2=80=99ve seen cases like this, but I=E2=80=99ve never =
seen a parameterization over predicates.<br></div></div></blockquote><div><=
br></div><div>That&#39;s because the construct isn&#39;t valid C++ today. :=
D =C2=A0But make it legal, and I predict that a lot of new code will happil=
y do away with all these wrapper classes and instead define only the entiti=
es that matter.</div><div>The practice of wrapping metaprogramming construc=
ts in wrapper classes (std::is_integral, etc.) is distinct from the practic=
e of bundling lots of data together into traits classes (std::allocator_tra=
its, std::numeric_limits, etc.). IMO, you confused the question a little bi=
t by naming your &quot;wrapper class&quot; in the above example <font face=
=3D"monospace, monospace">default_traits</font>, when for the purposes of t=
his example it&#39;s just a wrapper around=C2=A0<font face=3D"monospace, mo=
nospace">state</font>, not a bundle of related information.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div></div><d=
iv>If there=E2=80=99s one thing in there that needs work, it=E2=80=99s the =
busywork of putting the <font face=3D"Courier">typename</font> and <font fa=
ce=3D"Courier">template</font> keywords everywhere. That=E2=80=99s where co=
mmittee effort should go.<br></div></div></blockquote><div><br></div><div>C=
++11 template aliases have already solved that problem for type templates l=
ike <font face=3D"monospace, monospace">state</font>.</div><div><br></div><=
div><div><font face=3D"Courier">// Look ma, no busywork keywords!</font></d=
iv><div><font face=3D"Courier">template&lt; typename type, template &lt;typ=
ename...&gt; class state =3D default_state&lt; type &gt; &gt;</font></div><=
div><font face=3D"Courier">class specialized {</font></div><div><font face=
=3D"Courier">=C2=A0 =C2=A0 state&lt; specialized, int &gt; member;</font></=
div><div><font face=3D"Courier">=C2=A0 =C2=A0 =E2=80=A6</font></div><div><f=
ont face=3D"Courier">};</font></div></div><div><br></div><div>The remaining=
 problem is that the same feature doesn&#39;t work for variable templates o=
r function templates: it works <i>only</i> for class templates and template=
 aliases. That will change eventually, though. My bet is C++17.</div><div><=
br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

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

--001a11c3380e52997a050c97cc2a--

.

--Apple-Mail=_B69E267E-3E77-4C03-98E6-B49FDDADCEE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9314, at 3:36 PM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> Right. That's the current workaround for the lack of variable templates i=
n C++11, the lack of function template partial specialization in C++14, etc=
.. But that syntax is just *ridiculously* noisy.

The example isn=E2=80=99t working around any of those things. It=E2=80=99s =
the traits idiom, and the templates are bundled together with some other re=
lated stuff.

The noise of template template parameters is substantial. If the motivation=
 is to reduce noise, we need an alternative which is less verbose than temp=
late template parameters or wrapper classes, not more template template par=
ameters.

> It would be straightforward to put all templates on the same footing, now=
 that variable templates and template aliases (a.k.a. typedef templates) ha=
ve arrived. There's no reason to privilege class templates above all other =
templates, except that that's the way it was done in 1998.

The reason they can=E2=80=99t have exactly the same footing is that they ar=
en=E2=80=99t exactly the same thing. So far there=E2=80=99s no consensus on=
 how alias templates can be compared for equality.

> I=E2=80=99ve seen cases like this, but I=E2=80=99ve never seen a paramete=
rization over predicates.
>=20
> That's because the construct isn't valid C++ today. :D  But make it legal=
, and I predict that a lot of new code will happily do away with all these =
wrapper classes and instead define only the entities that matter.

I=E2=80=99m talking about the basic ideas, the constructs which can be expr=
essed in C++98 or any set of primitives (given a compiler up to the job). W=
hat wrapper classes? =E2=80=9CNew code will happily do away=E2=80=9D doesn=
=E2=80=99t make sense. Only old code can do away with old workarounds, and =
what I=E2=80=99ve been asking is what that old code is.

> The practice of wrapping metaprogramming constructs in wrapper classes (s=
td::is_integral, etc.) is distinct from the practice of bundling lots of da=
ta together into traits classes (std::allocator_traits, std::numeric_limits=
, etc.). IMO, you confused the question a little bit by naming your "wrappe=
r class" in the above example default_traits, when for the purposes of this=
 example it's just a wrapper around state, not a bundle of related informat=
ion.

It bundles state and trait. Even when there=E2=80=99s only one item, if it=
=E2=80=99s specific to the class at hand, the traits idiom can be a good id=
ea, providing room for expansion. Especially in this case, where some noise=
 is eliminated by doing so.

Passing std::is_integral vs std::is_pointer could be a different story, bec=
ause primary type categories aren=E2=80=99t very specific. But, it would be=
 nice to hear what that=E2=80=99s used for, or who=E2=80=99s doing it.

> If there=E2=80=99s one thing in there that needs work, it=E2=80=99s the b=
usywork of putting the typename and template keywords everywhere. That=E2=
=80=99s where committee effort should go.
>=20
> C++11 template aliases have already solved that problem for type template=
s like state.

Not quite, because an alias template can=E2=80=99t specialize to another un=
specialized template-name. In your example, default_state<type> cannot init=
ialize the parameter state so it must wrap a member template. Also, this on=
ly buys you one parameter.

> // busywork                  v              v     v                      =
              v        v
> template< typename type, template <typename...> class state =3D default_s=
tate< type >::template templ,
       class trait =3D default_trait< type > // < more busywork
> >
> class specialized {
>     state< specialized, int > member;
>     =E2=80=A6
> };
>=20
> The remaining problem is that the same feature doesn't work for variable =
templates or function templates: it works only for class templates and temp=
late aliases. That will change eventually, though. My bet is C++17.

The remaining problem is still template code littered with typename and tem=
plate, since not all member typedef-names and member templates can be conve=
rted to non-members. In particular, I think very few member function templa=
tes will ever be amenable.

Concepts provide a framework for declaring that a dependent type must conta=
in certain typenames and certain templates, which is a basis for chipping a=
way at the noise that pervades ordinary template code. Deep metaprogramming=
 is a niche, and if you=E2=80=99re doing a lot of it, you=E2=80=99re Doing =
it Wrong.

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

--Apple-Mail=_B69E267E-3E77-4C03-98E6-B49FDDADCEE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9314, at 3:36 PM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div class=3D"">Right. That's the current workaround for the lack of va=
riable templates in C++11, the lack of function template partial specializa=
tion in C++14, etc. But that syntax is just *ridiculously* noisy. </div></d=
iv></div></div></div></blockquote><div><br class=3D""></div><div>The exampl=
e isn=E2=80=99t working around any of those things. It=E2=80=99s the traits=
 idiom, and the templates are bundled together with some other related stuf=
f.</div><div><br class=3D""></div><div>The noise of template template param=
eters is substantial. If the motivation is to reduce noise, we need an alte=
rnative which is less verbose than template template parameters <i class=3D=
"">or</i>&nbsp;wrapper classes, not more template template parameters.</div=
><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div d=
ir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div class=3D"">It would be straightforward to put all =
templates on the same footing, now that variable templates and template ali=
ases (a.k.a. typedef templates) have arrived. There's no reason to privileg=
e class templates above all other templates, except that that's the way it =
was done in 1998.</div></div></div></div></div></blockquote><div><br class=
=3D""></div><div>The reason they can=E2=80=99t have exactly the same footin=
g is that they aren=E2=80=99t exactly the same thing. So far there=E2=80=99=
s no consensus on how alias templates can be compared for equality.</div><b=
r class=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
 normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px;" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div style=3D"word-wrap: break-word;" class=
=3D""><div class=3D""><font face=3D"Courier" class=3D""></font></div><div c=
lass=3D"">I=E2=80=99ve seen cases like this, but I=E2=80=99ve never seen a =
parameterization over predicates.<br class=3D""></div></div></blockquote><d=
iv class=3D""><br class=3D""></div><div class=3D"">That's because the const=
ruct isn't valid C++ today. :D &nbsp;But make it legal, and I predict that =
a lot of new code will happily do away with all these wrapper classes and i=
nstead define only the entities that matter.</div></div></div></div></block=
quote><div><br class=3D""></div><div>I=E2=80=99m talking about the basic id=
eas, the constructs which can be expressed in C++98 or any set of primitive=
s (given a compiler up to the job). What wrapper classes? =E2=80=9CNew code=
 will happily do away=E2=80=9D doesn=E2=80=99t make sense. Only old code ca=
n do away with old workarounds, and what I=E2=80=99ve been asking is what t=
hat old code is.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;=
 text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><div class=3D"">The practice of wrapping metaprogr=
amming constructs in wrapper classes (std::is_integral, etc.) is distinct f=
rom the practice of bundling lots of data together into traits classes (std=
::allocator_traits, std::numeric_limits, etc.). IMO, you confused the quest=
ion a little bit by naming your "wrapper class" in the above example<span c=
lass=3D"Apple-converted-space">&nbsp;</span><font face=3D"monospace, monosp=
ace" class=3D"">default_traits</font>, when for the purposes of this exampl=
e it's just a wrapper around&nbsp;<font face=3D"monospace, monospace" class=
=3D"">state</font>, not a bundle of related information.</div></div></div><=
/div></blockquote><div><br class=3D""></div><div>It bundles <font face=3D"C=
ourier" class=3D"">state</font> and <font face=3D"Courier" class=3D"">trait=
</font>. Even when there=E2=80=99s only one item, if it=E2=80=99s specific =
to the class at hand, the traits idiom can be a good idea, providing room f=
or expansion. Especially in this case, where some noise is eliminated by do=
ing so.</div><div><br class=3D""></div><div>Passing <font face=3D"Courier" =
class=3D"">std::is_integral</font> vs <font face=3D"Courier" class=3D"">std=
::is_pointer</font> could be a different story, because primary type catego=
ries aren=E2=80=99t very specific. But, it would be nice to hear what that=
=E2=80=99s used for, or who=E2=80=99s doing it.</div><br class=3D""><blockq=
uote type=3D"cite" class=3D""><div dir=3D"ltr" style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px=
; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-=
left: 1ex;"><div style=3D"word-wrap: break-word;" class=3D""><div class=3D"=
"></div><div class=3D"">If there=E2=80=99s one thing in there that needs wo=
rk, it=E2=80=99s the busywork of putting the<span class=3D"Apple-converted-=
space">&nbsp;</span><font face=3D"Courier" class=3D"">typename</font><span =
class=3D"Apple-converted-space">&nbsp;</span>and<span class=3D"Apple-conver=
ted-space">&nbsp;</span><font face=3D"Courier" class=3D"">template</font><s=
pan class=3D"Apple-converted-space">&nbsp;</span>keywords everywhere. That=
=E2=80=99s where committee effort should go.<br class=3D""></div></div></bl=
ockquote><div class=3D""><br class=3D""></div><div class=3D"">C++11 templat=
e aliases have already solved that problem for type templates like<span cla=
ss=3D"Apple-converted-space">&nbsp;</span><font face=3D"monospace, monospac=
e" class=3D"">state</font>.</div></div></div></div></blockquote><div><br cl=
ass=3D""></div><div>Not quite, because an alias template can=E2=80=99t spec=
ialize to another unspecialized template-name. In your example, <font face=
=3D"Courier" class=3D"">default_state&lt;type&gt;</font> cannot initialize =
the parameter <font face=3D"Courier" class=3D"">state</font>&nbsp;so it mus=
t wrap a member template. Also, this only buys you one parameter.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px;" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div class=3D""><div class=3D""><font face=3D"Courier" class=3D"">// busywor=
k &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v &nbsp; &nbsp; v &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;v &nbsp; &nbsp; &nbsp; &nbsp;v</font></div>=
<div class=3D""><font face=3D"Courier" class=3D"">template&lt; typename typ=
e, template &lt;typename...&gt; class state =3D default_state&lt; type &gt;=
::template templ,</font></div></div></div></div></div></blockquote><font fa=
ce=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp;class trait =3D defaul=
t_trait&lt; type &gt; // &lt; more busywork<br class=3D""></font><blockquot=
e type=3D"cite" class=3D""><div dir=3D"ltr" style=3D"font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div class=3D""><div class=3D""><font face=3D"=
Courier" class=3D""> &gt;</font></div><div class=3D"" style=3D"font-family:=
 Helvetica;"><font face=3D"Courier" class=3D"">class specialized {</font></=
div><div class=3D"" style=3D"font-family: Helvetica;"><font face=3D"Courier=
" class=3D"">&nbsp; &nbsp; state&lt; specialized, int &gt; member;</font></=
div><div class=3D"" style=3D"font-family: Helvetica;"><font face=3D"Courier=
" class=3D"">&nbsp; &nbsp; =E2=80=A6</font></div><div class=3D"" style=3D"f=
ont-family: Helvetica;"><font face=3D"Courier" class=3D"">};</font></div></=
div><div class=3D"" style=3D"font-family: Helvetica;"><br class=3D""></div>=
<div class=3D"" style=3D"font-family: Helvetica;">The remaining problem is =
that the same feature doesn't work for variable templates or function templ=
ates: it works<span class=3D"Apple-converted-space">&nbsp;</span><i class=
=3D"">only</i><span class=3D"Apple-converted-space">&nbsp;</span>for class =
templates and template aliases. That will change eventually, though. My bet=
 is C++17.</div></div></div></div></blockquote><div><br class=3D""></div>Th=
e remaining problem is still template code littered with <font face=3D"Cour=
ier" class=3D"">typename</font> and <font face=3D"Courier" class=3D"">templ=
ate</font>, since not all member typedef-names and member templates can be =
converted to non-members. In particular, I think very few member function t=
emplates will ever be amenable.</div><div><br class=3D""></div><div>Concept=
s provide a framework for declaring that a dependent type must contain cert=
ain typenames and certain templates, which is a basis for chipping away at =
the noise that pervades ordinary template code. Deep metaprogramming is a n=
iche, and if you=E2=80=99re doing a lot of it, you=E2=80=99re Doing it Wron=
g.</div></body></html>

<p></p>

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

--Apple-Mail=_B69E267E-3E77-4C03-98E6-B49FDDADCEE9--

.

David Krauss <potswa@gmail.com> writes:

| > On 2015=E2=80=9301=E2=80=9314, at 5:59 AM, Ville Voutilainen
| > <ville.voutilainen@gmail.com> wrote:
| >=20
| > On 13 January 2015 at 23:52, David Krauss <potswa@gmail.com> wrote:
| >> Overloading and partial specialization were omitted from variable temp=
lates
| >> on purpose.
| >=20
| > So on purpose, that they allow partial specialization?
|=20
| Do they?

Yes.

-- Gaby

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

.

David Krauss <potswa@gmail.com> writes:

| > On 2015=E2=80=9301=E2=80=9314, at 6:25 AM, Ville Voutilainen
| > <ville.voutilainen@gmail.com> wrote:
| >=20
| > On 14 January 2015 at 00:24, David Krauss <potswa@gmail.com> wrote:
| >>> So on purpose, that they allow partial specialization?
| >> Do they? The specification of VTs is scattered and incomplete, but
| >> I don=E2=80=99t see where the C++14 IS
| >=20
| > Yes, they do. That was always the design intent.
|=20
| Digging deeper, so far, the specification has only got as far as DR
| 1711, which is in the drafting stage with no proposed resolution.

I am the "drafter", with clear direction agreed upon by CWG.  There is no
surprise as what the intent is, what the outcome should be.  The
omission is the result of wording snafu -- not by design.

-- Gaby

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

.

--90e6ba613670c88f75050cb77a5a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue Jan 13 2015 at 3:23:34 PM David Krauss <potswa@gmail.com> wrote:

> The gain in this example is to replace template< typename > class with
> auto. But that=E2=80=99s not compatible with the proposal at hand.
>
> I don't find this as a motivating example to support the feature on its
own, but may add up a bit.

In the past I have tried to write a template similar to:

template<typename T, int T::*>
struct ptr_to_member { ... };

Which would be used as:

ptr_to_member<Type, &Type::member> ptm;

Now this is somehow problematic, as the type of '&Type::member' may not be
a pointer-to-member of 'Type', in particular if the member is defined in a
base:

struct Base { int member; };
struct Derived : Base {};
ptr_to_member<Derived, &Derived::member> ptm;

The workaround here is that the user needs to dig into the details of how
'Derived' is defined and whether it uses inheritance to figure out what the
correct type to use is:

ptr_to_member<Base, &Derived::member> ptm;

Note that the fact that the expression yields a 'int Base::*' does not
matter to most code, since there is an implicit conversion from 'int
Base::*' to 'int Derived::*', except that this conversion is not available
when specializing a template.

Also, while it can be argued that the user should be able to peek into the
headers and figure out where the member is defined, that is not always the
case. In particular, I don't think you can use the above template with any
standard container, as most implementations use inheritance to specialize
behavior:

ptr_to_member<???, &std::vector<int>::push_back> ptm;

Personally I believe this to be an error in the standard,
'&Derived::member' *should* yield a 'int Derived::*', not an 'int Base::*',
but putting that aside, the current proposal would enable the above by just
having:

template <auto PtrToMbr>
struct ptr_to_member { ... };
ptr_to_member<&Derived::member> ptm;
ptr_to_member<&std::vector<int>::push_back> ptm2;

While I imagine that most people spend a lifetime without ever caring about
this particular, here are my 2c.

     David

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

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

<br><br><div class=3D"gmail_quote">On Tue Jan 13 2015 at 3:23:34 PM David K=
rauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>&gt; wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><d=
iv><div>The gain in this example is to replace <font face=3D"Courier">templ=
ate&lt; typename &gt; class</font> with <font face=3D"Courier">auto</font>.=
 But that=E2=80=99s not compatible with the proposal at hand.</div><div><br=
></div></div></div></blockquote><div>I don&#39;t find this as a motivating =
example to support the feature on its own, but may add up a bit. =C2=A0<br>=
<br>In the past I have tried to write a template similar to:<br><br>templat=
e&lt;typename T, int T::*&gt;<br>struct ptr_to_member { ... };<br><br>Which=
 would be used as:<br><br>ptr_to_member&lt;Type, &amp;Type::member&gt; ptm;=
<br><br>Now this is somehow problematic, as the type of &#39;&amp;Type::mem=
ber&#39; may not be a pointer-to-member of &#39;Type&#39;, in particular if=
 the member is defined in a base:<br><br>struct Base { int member; };<br>st=
ruct Derived : Base {};<br>ptr_to_member&lt;Derived, &amp;Derived::member&g=
t; ptm;<br><br>The workaround here is that the user needs to dig into the d=
etails of how &#39;Derived&#39; is defined and whether it uses inheritance =
to figure out what the correct type to use is:<br><br>ptr_to_member&lt;Base=
, &amp;Derived::member&gt; ptm;<br><br>Note that the fact that the expressi=
on yields a &#39;int Base::*&#39; does not matter to most code, since there=
 is an implicit conversion from &#39;int Base::*&#39; to &#39;int Derived::=
*&#39;, except that this conversion is not available when specializing a te=
mplate.<br><br>Also, while it can be argued that the user should be able to=
 peek into the headers and figure out where the member is defined, that is =
not always the case. In particular, I don&#39;t think you can use the above=
 template with any standard container, as most implementations use inherita=
nce to specialize behavior:<br><br>ptr_to_member&lt;???, &amp;std::vector&l=
t;int&gt;::push_back&gt; ptm;<br><br>Personally I believe this to be an err=
or in the standard, &#39;&amp;Derived::member&#39; *should* yield a &#39;in=
t Derived::*&#39;, not an &#39;int Base::*&#39;, but putting that aside, th=
e current proposal would enable the above by just having:<br><br>template &=
lt;auto PtrToMbr&gt;<br>struct ptr_to_member { ... };<br>ptr_to_member&lt;&=
amp;Derived::member&gt; ptm;<br>ptr_to_member&lt;&amp;std::vector&lt;int&gt=
;::push_back&gt; ptm2;<br><br></div><div>While I imagine that most people s=
pend a lifetime without ever caring about this particular, here are my 2c.<=
br><br>=C2=A0 =C2=A0 =C2=A0David<br><br></div></div>

<p></p>

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

--90e6ba613670c88f75050cb77a5a--

.

------=_Part_166_1280252499.1421363782972
Content-Type: multipart/alternative;
 boundary="----=_Part_167_1565091400.1421363782972"

------=_Part_167_1565091400.1421363782972
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1
Member function pointers definitely make a good case-and-point for the=20
importance of what this proposal means to achieve.

On Thursday, January 15, 2015 at 4:24:23 PM UTC-5, David Rodr=C3=ADguez Ibe=
as=20
wrote:
>
>
>
> On Tue Jan 13 2015 at 3:23:34 PM David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:
>
>> The gain in this example is to replace template< typename > class with=
=20
>> auto. But that=E2=80=99s not compatible with the proposal at hand.
>>
>> I don't find this as a motivating example to support the feature on its=
=20
> own, but may add up a bit. =20
>
> In the past I have tried to write a template similar to:
>
> template<typename T, int T::*>
> struct ptr_to_member { ... };
>
> Which would be used as:
>
> ptr_to_member<Type, &Type::member> ptm;
>
> Now this is somehow problematic, as the type of '&Type::member' may not b=
e=20
> a pointer-to-member of 'Type', in particular if the member is defined in =
a=20
> base:
>
> struct Base { int member; };
> struct Derived : Base {};
> ptr_to_member<Derived, &Derived::member> ptm;
>
> The workaround here is that the user needs to dig into the details of how=
=20
> 'Derived' is defined and whether it uses inheritance to figure out what t=
he=20
> correct type to use is:
>
> ptr_to_member<Base, &Derived::member> ptm;
>
> Note that the fact that the expression yields a 'int Base::*' does not=20
> matter to most code, since there is an implicit conversion from 'int=20
> Base::*' to 'int Derived::*', except that this conversion is not availabl=
e=20
> when specializing a template.
>
> Also, while it can be argued that the user should be able to peek into th=
e=20
> headers and figure out where the member is defined, that is not always th=
e=20
> case. In particular, I don't think you can use the above template with an=
y=20
> standard container, as most implementations use inheritance to specialize=
=20
> behavior:
>
> ptr_to_member<???, &std::vector<int>::push_back> ptm;
>
> Personally I believe this to be an error in the standard,=20
> '&Derived::member' *should* yield a 'int Derived::*', not an 'int Base::*=
',=20
> but putting that aside, the current proposal would enable the above by ju=
st=20
> having:
>
> template <auto PtrToMbr>
> struct ptr_to_member { ... };
> ptr_to_member<&Derived::member> ptm;
> ptr_to_member<&std::vector<int>::push_back> ptm2;
>
> While I imagine that most people spend a lifetime without ever caring=20
> about this particular, here are my 2c.
>
>      David
>
>

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

------=_Part_167_1565091400.1421363782972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>+1</div>Member function pointers definitely make a go=
od case-and-point for the importance of what this proposal means to achieve=
..<div><br>On Thursday, January 15, 2015 at 4:24:23 PM UTC-5, David Rodr=C3=
=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br><d=
iv class=3D"gmail_quote">On Tue Jan 13 2015 at 3:23:34 PM David Krauss &lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"DcwZ7gsq=
OwYJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gmail.com</a>&=
gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word"><div><div>The gain in this example is to replace <font face=3D"Courie=
r">template&lt; typename &gt; class</font> with <font face=3D"Courier">auto=
</font>. But that=E2=80=99s not compatible with the proposal at hand.</div>=
<div><br></div></div></div></blockquote><div>I don't find this as a motivat=
ing example to support the feature on its own, but may add up a bit. &nbsp;=
<br><br>In the past I have tried to write a template similar to:<br><br>tem=
plate&lt;typename T, int T::*&gt;<br>struct ptr_to_member { ... };<br><br>W=
hich would be used as:<br><br>ptr_to_member&lt;Type, &amp;Type::member&gt; =
ptm;<br><br>Now this is somehow problematic, as the type of '&amp;Type::mem=
ber' may not be a pointer-to-member of 'Type', in particular if the member =
is defined in a base:<br><br>struct Base { int member; };<br>struct Derived=
 : Base {};<br>ptr_to_member&lt;Derived, &amp;Derived::member&gt; ptm;<br><=
br>The workaround here is that the user needs to dig into the details of ho=
w 'Derived' is defined and whether it uses inheritance to figure out what t=
he correct type to use is:<br><br>ptr_to_member&lt;Base, &amp;Derived::memb=
er&gt; ptm;<br><br>Note that the fact that the expression yields a 'int Bas=
e::*' does not matter to most code, since there is an implicit conversion f=
rom 'int Base::*' to 'int Derived::*', except that this conversion is not a=
vailable when specializing a template.<br><br>Also, while it can be argued =
that the user should be able to peek into the headers and figure out where =
the member is defined, that is not always the case. In particular, I don't =
think you can use the above template with any standard container, as most i=
mplementations use inheritance to specialize behavior:<br><br>ptr_to_member=
&lt;???, &amp;std::vector&lt;int&gt;::push_back&gt; ptm;<br><br>Personally =
I believe this to be an error in the standard, '&amp;Derived::member' *shou=
ld* yield a 'int Derived::*', not an 'int Base::*', but putting that aside,=
 the current proposal would enable the above by just having:<br><br>templat=
e &lt;auto PtrToMbr&gt;<br>struct ptr_to_member { ... };<br>ptr_to_member&l=
t;&amp;Derived::<wbr>member&gt; ptm;<br>ptr_to_member&lt;&amp;std::vector&l=
t;<wbr>int&gt;::push_back&gt; ptm2;<br><br></div><div>While I imagine that =
most people spend a lifetime without ever caring about this particular, her=
e are my 2c.<br><br>&nbsp; &nbsp; &nbsp;David<br><br></div></div>
</blockquote></div></div>

<p></p>

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

------=_Part_167_1565091400.1421363782972--
------=_Part_166_1280252499.1421363782972--

.

--Apple-Mail=_351AC70A-6428-4270-9373-56F8F853B679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9316, at 5:24 AM, David Rodr=C3=ADguez Ibeas <di=
beas@ieee.org> wrote:
>=20
>=20
>=20
> On Tue Jan 13 2015 at 3:23:34 PM David Krauss <potswa@gmail.com <mailto:p=
otswa@gmail.com>> wrote:
> The gain in this example is to replace template< typename > class with au=
to. But that=E2=80=99s not compatible with the proposal at hand.
>=20
> I don't find this as a motivating example to support the feature on its o=
wn, but may add up a bit. =20

I do support the OP proposal, but Arthur is suggesting something else. His =
example does not add support. Sorry, I=E2=80=99ve added a lot of noise to t=
his thread.

> ptr_to_member<Type, &Type::member> ptm;
>=20
> Now this is somehow problematic, as the type of '&Type::member' may not b=
e a pointer-to-member of 'Type', in particular if the member is defined in =
a base:

I=E2=80=99m not sure why the implicit conversion is disallowed here, but C+=
+17 relaxes the draconian rules for template non-type arguments. If this ca=
se isn=E2=80=99t fixed, there should be a DR.

Anyway, the proposal would patch the error independently by allowing templa=
te< typename t, auto ptm >. Then the user can pass any value at all in ptm =
 including base class members. It=E2=80=99s up to the template to sanitize.

> In particular, I don't think you can use the above template with any stan=
dard container, as most implementations use inheritance to specialize behav=
ior:
>=20
> ptr_to_member<???, &std::vector<int>::push_back> ptm;

You can=E2=80=99t take the address of any standard member function because =
the implementation is allowed to add defaulted parameters and overloads.

> Personally I believe this to be an error in the standard, '&Derived::memb=
er' *should* yield a 'int Derived::*', not an 'int Base::*', but putting th=
at aside, the current proposal would enable the above by just having:
>=20
> template <auto PtrToMbr>
> struct ptr_to_member { ... };
> ptr_to_member<&Derived::member> ptm;

Agreed.

> While I imagine that most people spend a lifetime without ever caring abo=
ut this particular, here are my 2c.

The frequency is proportional to usage of PTMs in the first place. I don=E2=
=80=99t often use PTMs, but when I do, they=E2=80=99re usually non-type tem=
plate parameters. Then the overhead is kept equal to an ordinary member acc=
ess/call.

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

--Apple-Mail=_351AC70A-6428-4270-9373-56F8F853B679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9316, at 5:24 AM, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:d=
ibeas@ieee.org" class=3D"">dibeas@ieee.org</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><br class=3D""><br class=3D""><=
div class=3D"gmail_quote">On Tue Jan 13 2015 at 3:23:34 PM David Krauss &lt=
;<a href=3D"mailto:potswa@gmail.com" class=3D"">potswa@gmail.com</a>&gt; wr=
ote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:b=
reak-word" class=3D""><div class=3D""><div class=3D"">The gain in this exam=
ple is to replace <font face=3D"Courier" class=3D"">template&lt; typename &=
gt; class</font> with <font face=3D"Courier" class=3D"">auto</font>. But th=
at=E2=80=99s not compatible with the proposal at hand.</div><div class=3D""=
><br class=3D""></div></div></div></blockquote><div class=3D"">I don't find=
 this as a motivating example to support the feature on its own, but may ad=
d up a bit. &nbsp;<br class=3D""></div></div></div></blockquote><div><br cl=
ass=3D""></div><div>I do support the OP proposal, but Arthur is suggesting =
something else. His example does not add support. Sorry, I=E2=80=99ve added=
 a lot of noise to this thread.</div><br class=3D""><blockquote type=3D"cit=
e" class=3D""><div class=3D""><div class=3D"gmail_quote"><div class=3D"">pt=
r_to_member&lt;Type, &amp;Type::member&gt; ptm;<br class=3D""><br class=3D"=
">Now this is somehow problematic, as the type of '&amp;Type::member' may n=
ot be a pointer-to-member of 'Type', in particular if the member is defined=
 in a base:<br class=3D""></div></div></div></blockquote><div><br class=3D"=
"></div><div>I=E2=80=99m not sure why the implicit conversion is disallowed=
 here, but C++17 relaxes the draconian rules for template non-type argument=
s. If this case isn=E2=80=99t fixed, there should be a DR.</div><div><br cl=
ass=3D""></div><div>Anyway, the proposal would patch the error independentl=
y by allowing <font face=3D"Courier" class=3D"">template&lt; typename t, au=
to ptm &gt;</font>. Then the user can pass any value at all in&nbsp;<span s=
tyle=3D"font-family: Courier;" class=3D"">ptm</span>&nbsp; including base c=
lass members. It=E2=80=99s up to the template to sanitize.</div><div><br cl=
ass=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div cl=
ass=3D"gmail_quote"><div class=3D"">In particular, I don't think you can us=
e the above template with any standard container, as most implementations u=
se inheritance to specialize behavior:</div></div></div></blockquote><block=
quote type=3D"cite" class=3D""><div class=3D""><div class=3D"gmail_quote"><=
div class=3D""><br class=3D"">ptr_to_member&lt;???, &amp;std::vector&lt;int=
&gt;::push_back&gt; ptm;<br class=3D""></div></div></div></blockquote><div>=
<br class=3D""></div><div>You can=E2=80=99t take the address of any standar=
d member function because the implementation is allowed to add defaulted pa=
rameters and overloads.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div class=3D"gmail_quote"><div class=3D"">Personally=
 I believe this to be an error in the standard, '&amp;Derived::member' *sho=
uld* yield a 'int Derived::*', not an 'int Base::*', but putting that aside=
, the current proposal would enable the above by just having:<br class=3D""=
><br class=3D"">template &lt;auto PtrToMbr&gt;<br class=3D"">struct ptr_to_=
member { ... };<br class=3D"">ptr_to_member&lt;&amp;Derived::member&gt; ptm=
;<br class=3D""></div></div></div></blockquote><div><br class=3D""></div><d=
iv>Agreed.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><div class=3D"gmail_quote"><div class=3D"">While I imagine that mo=
st people spend a lifetime without ever caring about this particular, here =
are my 2c.</div></div></div></blockquote></div><br class=3D""><div class=3D=
"">The frequency is proportional to usage of PTMs in the first place. I don=
=E2=80=99t often use PTMs, but when I do, they=E2=80=99re usually non-type =
template parameters. Then the overhead is kept equal to an ordinary member =
access/call.</div></body></html>

<p></p>

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

--Apple-Mail=_351AC70A-6428-4270-9373-56F8F853B679--

.

On Thu, Jan 15, 2015 at 5:28 PM, David Krauss <potswa@gmail.com> wrote:
> On Thu, Jan 15, 2015 at 1:24 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.=
org> wrote:
> > ptr_to_member<Type, &Type::member> ptm;
> >
> > Now this is somehow problematic, as the type of '&Type::member' may not=
 be a
> > pointer-to-member of 'Type', in particular if the member is defined in =
a
> > base:
>
> I=E2=80=99m not sure why the implicit conversion is disallowed here, but =
C++17
> relaxes the draconian rules for template non-type arguments. If this case
> isn=E2=80=99t fixed, there should be a DR.

This is still not allowed. We're very restrictive about which
conversions we allow implicitly at the top level in a converted
constant expression, and those restrictions currently cover this case.
We could certainly relax this rule -- there's plenty of time before
C++17 -- but I was trying to avoid scope creep in N4198 so this was
not covered there.

The good-ish news is that you can at least now write

ptr_to_member<Type, (int Type::*)&Type::member> ptm;

(but due to the lack of a mangling for this template argument, Clang's
C++17 mode does not yet allow this).

On Thu, Jan 15, 2015 at 1:24 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g> wrote:
> Personally I believe this to be an error in the standard, '&Derived::memb=
er'
> *should* yield a 'int Derived::*', not an 'int Base::*'

I agree; there have been some previous attempts to fix this:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#203
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1007

It looks like we're mostly waiting for someone to write a paper for EWG.

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

.

--Apple-Mail=_14131C63-964D-4A6B-A05C-C122FED28FBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9317, at 9:07 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>=20
> This is still not allowed. We're very restrictive about which
> conversions we allow implicitly at the top level in a converted
> constant expression, and those restrictions currently cover this case.
> We could certainly relax this rule -- there's plenty of time before
> C++17 -- but I was trying to avoid scope creep in N4198 so this was
> not covered there.

N4198 is what introduced the link between converted constant expressions an=
d template non-type arguments, adding cases to the former to accommodate no=
n-integer types. It looks like you chose this as an evolutionary middle gro=
und.

I would expect non-type parameters to be initialized the same way as conste=
xpr variables. Perhaps another proposal could make the leap from =E2=80=9Cc=
onverted constant expression=E2=80=9D to =E2=80=9Cconstexpr initialization=
=E2=80=9D? (Albeit with the complete object and linkage restrictions for po=
inters and references.)

What trouble is avoided by requiring the conversions to be stated explicitl=
y? I would think that the implementation complexity would come from having =
them at all, regardless of syntax. Would a proposal for constexpr-like init=
ialization have any other impact besides removing the syntactic requirement=
 for some static_casts?

> I agree; there have been some previous attempts to fix this:
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#203
>=20
> It looks like we're mostly waiting for someone to write a paper for EWG.

That DR looks almost like a paper already. Hope someone will adopt the caus=
e.

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

--Apple-Mail=_14131C63-964D-4A6B-A05C-C122FED28FBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9317, at 9:07 AM, Richard Smith &lt;<a href=3D"mailto:richard@metafo=
o.co.uk" class=3D"">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D"">This is still not allowed. We're=
 very restrictive about which<br class=3D"">conversions we allow implicitly=
 at the top level in a converted<br class=3D"">constant expression, and tho=
se restrictions currently cover this case.<br class=3D"">We could certainly=
 relax this rule -- there's plenty of time before<br class=3D"">C++17 -- bu=
t I was trying to avoid scope creep in N4198 so this was<br class=3D"">not =
covered there.<br class=3D""></div></blockquote><div><br class=3D""></div><=
div>N4198 is what introduced the link between converted constant expression=
s and template non-type arguments, adding cases to the former to accommodat=
e non-integer types. It looks like you chose this as an evolutionary middle=
 ground.</div><div><br class=3D""></div><div>I would expect non-type parame=
ters to be initialized the same way as constexpr variables. Perhaps another=
 proposal could make the leap from =E2=80=9Cconverted constant expression=
=E2=80=9D to =E2=80=9Cconstexpr initialization=E2=80=9D? (Albeit with the c=
omplete object and linkage restrictions for pointers and references.)</div>=
<div><br class=3D""></div><div>What trouble is avoided by requiring the con=
versions to be stated explicitly? I would think that the implementation com=
plexity would come from having them at all, regardless of syntax. Would a p=
roposal for constexpr-like initialization have any other impact besides rem=
oving the syntactic requirement for some <font face=3D"Courier" class=3D"">=
static_cast</font>s?</div><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D"">I agree; there have been some previous attempts to fix t=
his:<br class=3D""><br class=3D""><a href=3D"http://www.open-std.org/jtc1/s=
c22/wg21/docs/cwg_closed.html#203" class=3D"">http://www.open-std.org/jtc1/=
sc22/wg21/docs/cwg_closed.html#203</a><br class=3D""><br class=3D"">It look=
s like we're mostly waiting for someone to write a paper for EWG.<br class=
=3D""></div></blockquote><div><br class=3D""></div>That DR looks almost lik=
e a paper already. Hope someone will adopt the cause.</div></body></html>

<p></p>

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

--Apple-Mail=_14131C63-964D-4A6B-A05C-C122FED28FBE--

.

------=_Part_1032_1569128382.1422923062791
Content-Type: multipart/alternative;
 boundary="----=_Part_1033_1241531114.1422923062792"

------=_Part_1033_1241531114.1422923062792
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Resurrecting this old thread to add...
Wow! I had no idea that that "is_template_specialized()" trick actually=20
worked!  (I skimmed over the details when this message first hit my inbox.)=
=20
 But indeed, you're right; C++ allows us to introspect a little bit on the=
=20
"structure" of a type, and yes, if we allow template template parameters to=
=20
be things other than type templates, we will *also* be able to introspect=
=20
to the same degree on the "structure" of non-types.  I agree that that's a=
=20
horrific abuse of partial specialization, but I wouldn't propose to remove=
=20
it from the language.
Here's your code rewritten to use regular old template template parameters=
=20
instead of the proposed new feature:

#include <type_traits>


template<typename T> struct is_typename_parameterized : std::false_type {};

template<template<class> class C, class P> struct=20
is_typename_parameterized<C<P>> : std::true_type {};


template<typename> class Class {};

template<typename> using Alias =3D int;

template<typename> using AliasForClass =3D Class<int>;


static_assert(is_typename_parameterized< int >() =3D=3D false, "");

static_assert(is_typename_parameterized< Alias<int> >() =3D=3D false, ""); =
  //=20
these two lines

static_assert(is_typename_parameterized< Class<int> >() =3D=3D true, "");  =
  //=20
are the horrific part

static_assert(is_typename_parameterized< AliasForClass<int> >() =3D=3D true=
,=20
"");

Indeed, it's 100% valid C++11.

=E2=80=93Arthur

On Monday, January 12, 2015 at 6:25:33 PM UTC-8, David Krauss wrote:
>
>
> On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager <splinte...@gmail=
..com=20
> <javascript:>> wrote:
>
> A little off-topic in this thread, but being able to pass a variable=20
> template as a parameter when the type parameter is unknown would be nice.=
=20
> It would make them much more useful in template meta-programming.
>
>
> Is there a real use-case? Variable templates are a convenience, but=20
> they=E2=80=99re not primitive. You can emulate them with class-based meta=
functions.=20
> Passing a variable template as a metafunction likewise only requires a=20
> wrapper class.
>
> Applying this solution to the previous (unrealistic) example,
>
> template<typename T> T pi =3D static_cast<T>(3.14);
>
> template< typename T >
> struct pi_as_metafunction {
>     static T const & value =3D pi< T >;
> };
>
> template<template<typename T> class P> int int_plus_one =3D P<int>::value=
 +=20
> 1;
>
> int main()
> {
>     return int_plus_one<pi_as_metafunction>;  // which is pi<int> + 1,=20
> which is 4
> }
>
> What this doesn=E2=80=99t support is partial specialization, i.e. recover=
ing the=20
> int parameter from pi<int>. However, is that something we really want? It=
=20
> would support such abuse as,
>
> template< int const & obj >
> struct is_typename_parameterized : std::false_type {};
>
> template< template< typename type > int const & templ, typename param >
> struct is_typename_parameterized< templ< param > > : std::true_type {};
>
> int x;
> constexpr int const * nums[] =3D { & x, & pi< int > };
>
> static_assert( ! is_typename_parameterized< * nums[0] >();
> static_assert( is_typename_parameterized< * nums[1] >();
>
> Having the computed address of a variable template specialization behave=
=20
> differently from the template-id of the specialization would introduce ye=
t=20
> another kind of expression: more complicated rules to support corner case=
s=20
> of more arcane syntax.
>
> Metaprogramming is complicated enough using the identities and properties=
=20
> of types. Sending different variables into different templates is madness=
,=20
> and not something to be made more convenient. (It is already possible to =
do=20
> this sort of thing using SFINAE and wrapper classes, so we=E2=80=99re not=
 even=20
> talking about added capability.)
>
> Likewise, we=E2=80=99ve had function templates for a long time, but nobod=
y ever=20
> wishes for template parameters that are unspecialized function templates.
>

> The C++ template system is the last place we should be pursuing solutions=
=20
> in search of a problem.
>

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

------=_Part_1033_1241531114.1422923062792
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Resurrecting this old thread to add...</div><div>Wow!=
 I had no idea that that "is_template_specialized()" trick actually worked!=
 &nbsp;(I skimmed over the details when this message first hit my inbox.) &=
nbsp;But indeed, you're right; C++ allows us to introspect a little bit on =
the "structure" of a type, and yes, if we allow template template parameter=
s to be things other than type templates, we will *also* be able to introsp=
ect to the same degree on the "structure" of non-types. &nbsp;I agree that =
that's a horrific abuse of partial specialization, but I wouldn't propose t=
o remove it from the language.</div><div>Here's your code rewritten to use =
regular old template template parameters instead of the proposed new featur=
e:</div><div><br></div><div><p style=3D"margin-bottom: 0px; font-size: 11px=
; line-height: normal; font-family: Menlo;">#include &lt;type_traits&gt;</p=
>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo; min-height: 13px;"><br></p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">template&lt;typename T&gt; struct is_typename_parameterized=
 : std::false_type {};</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">template&lt;template&lt;class&gt; class C, class P&gt; stru=
ct is_typename_parameterized&lt;C&lt;P&gt;&gt; : std::true_type {};</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo; min-height: 13px;"><br></p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">template&lt;typename&gt; class Class {};</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">template&lt;typename&gt; using Alias =3D int;</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">template&lt;typename&gt; using AliasForClass =3D Class&lt;i=
nt&gt;;</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo; min-height: 13px;"><br></p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">static_assert(is_typename_parameterized&lt; int &gt;() =3D=
=3D false, "");</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">static_assert(is_typename_parameterized&lt; Alias&lt;int&gt=
; &gt;() =3D=3D false, ""); &nbsp; // these two lines</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">static_assert(is_typename_parameterized&lt; Class&lt;int&gt=
; &gt;() =3D=3D true, ""); &nbsp; &nbsp;// are the horrific part</p>
<p style=3D"margin-bottom: 0px; font-size: 11px; line-height: normal; font-=
family: Menlo;">static_assert(is_typename_parameterized&lt; AliasForClass&l=
t;int&gt; &gt;() =3D=3D true, "");</p></div><br>Indeed, it's 100% valid C++=
11.<div><br></div><div>=E2=80=93Arthur<div><br>On Monday, January 12, 2015 =
at 6:25:33 PM UTC-8, David Krauss wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"=
cite"><div>On 2015=E2=80=9301=E2=80=9313, at 7:29 AM, Scott Prager &lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"UCdpWiq1BU8J=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">splinte...@gmail.com</a>&=
gt; wrote:</div><br><div><span style=3D"font-family:Helvetica;font-size:13p=
x;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:n=
ormal;line-height:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px;float:none;display:inline!important"=
>A little off-topic in this thread, but being able to pass a variable templ=
ate as a parameter when the type parameter is unknown would be nice. It wou=
ld make them much more useful in template meta-programming.</span></div></b=
lockquote></div><br><div>Is there a real use-case? Variable templates are a=
 convenience, but they=E2=80=99re not primitive. You can emulate them with =
class-based metafunctions. Passing a variable template as a metafunction li=
kewise only requires a wrapper class.</div><div><br></div><div>Applying thi=
s solution to the previous (unrealistic) example,</div><div><br></div><div>=
<font face=3D"Courier">template&lt;typename T&gt; T pi =3D static_cast&lt;T=
&gt;(3.14);</font></div><div><font face=3D"Courier"><br></font></div><div><=
font face=3D"Courier">template&lt; typename T &gt;</font></div><div><font f=
ace=3D"Courier">struct pi_as_metafunction {</font></div><div><font face=3D"=
Courier">&nbsp; &nbsp; static T const &amp; value =3D pi&lt; T &gt;;</font>=
</div><div><font face=3D"Courier">};</font></div><div><font face=3D"Courier=
"><br>template&lt;template&lt;typename T&gt; class P&gt; int int_plus_one =
=3D P&lt;int&gt;::value + 1;</font></div><div><font face=3D"Courier"><br>in=
t main()<br>{<br>&nbsp; &nbsp; return int_plus_one&lt;pi_as_<wbr>metafuncti=
on&gt;; &nbsp;// which is pi&lt;int&gt; + 1, which is 4<br>}<br></font></di=
v><div><br></div><div>What this doesn=E2=80=99t support is partial speciali=
zation, i.e. recovering the int parameter from <font face=3D"Courier">pi&lt=
;int&gt;</font>. However, is that something we really want? It would suppor=
t such abuse as,</div><div><br></div><div><font face=3D"Courier">template&l=
t; int const &amp; obj &gt;</font></div><div><font face=3D"Courier">struct =
is_typename_parameterized : std::false_type {};</font></div><div><font face=
=3D"Courier"><br></font></div><div><font face=3D"Courier">template&lt; temp=
late&lt; typename type &gt; int const &amp; templ, typename param &gt;</fon=
t></div><div><font face=3D"Courier">struct is_typename_parameterized&lt;&nb=
sp;<wbr>templ&lt; param &gt; &gt;</font><span style=3D"font-family:Courier"=
>&nbsp;</span><span style=3D"font-family:Courier">: std::true_type {};</spa=
n></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Cou=
rier">int x;</font></div><div><font face=3D"Courier">constexpr int const * =
nums[] =3D { &amp; x, &amp; pi&lt; int &gt; };</font></div><div><font face=
=3D"Courier"><br></font></div><div><font face=3D"Courier">static_assert( ! =
is_typename_parameterized&lt; * nums[0] &gt;();</font></div><div><div><font=
 face=3D"Courier">static_assert( is_typename_parameterized&lt; * nums[1] &g=
t;();</font></div></div><div><br></div><div>Having the computed address of =
a variable template specialization behave differently from the template-id =
of the specialization would introduce yet another kind of expression: more =
complicated rules to support corner cases of more arcane syntax.</div><div>=
<br></div><div>Metaprogramming is complicated enough using the identities a=
nd properties of types. Sending different variables into different template=
s is madness, and not something to be made more convenient. (It is already =
possible to do this sort of thing using SFINAE and wrapper classes, so we=
=E2=80=99re not even talking about added capability.)</div><div><br></div><=
div>Likewise, we=E2=80=99ve had function templates for a long time, but nob=
ody ever wishes for template parameters that are unspecialized function tem=
plates.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div style=3D"word-wrap:break-word"><div><br></div><div>The C++ template =
system is the last place we should be pursuing solutions in search of a pro=
blem.</div></div></blockquote></div></div></div>

<p></p>

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

------=_Part_1033_1241531114.1422923062792--
------=_Part_1032_1569128382.1422923062791--

.

--Apple-Mail=_80860199-9CCF-4039-8DE5-AED97501C5B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9303, at 8:24 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> static_assert(is_typename_parameterized< Alias<int> >() =3D=3D false, "")=
;   // these two lines
> static_assert(is_typename_parameterized< Class<int> >() =3D=3D true, "");=
    // are the horrific part

An alias template is never deduced. Names of alias template specializations=
 are ephemeral; they are substituted at template definition time, not insta=
ntiation time when parameters are available. (This is why we can=E2=80=99t =
have alias template specializations: the definition cannot depend on the ar=
guments.)

So, whereas the line mentioning Class<int> can inspect the identity of a pa=
rticular class, the one mentioning Alias<int> will never be able to observe=
 anything but the int produced by its substitution.

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

--Apple-Mail=_80860199-9CCF-4039-8DE5-AED97501C5B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9303, at 8:24 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><p style=3D"font-style:=
 normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
 line-height: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; margin-bottom: 0px; font-size: 11px; font-f=
amily: Menlo;" class=3D"">static_assert(is_typename_parameterized&lt; Alias=
&lt;int&gt; &gt;() =3D=3D false, ""); &nbsp; // these two lines</p><p style=
=3D"font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; margin-bottom: 0px; font-siz=
e: 11px; font-family: Menlo;" class=3D"">static_assert(is_typename_paramete=
rized&lt; Class&lt;int&gt; &gt;() =3D=3D true, ""); &nbsp; &nbsp;// are the=
 horrific part</p></div></blockquote></div><br class=3D""><div class=3D"">A=
n alias template is never deduced. Names of alias template specializations =
are ephemeral; they are substituted at template definition time, not instan=
tiation time when parameters are available. (This is why we can=E2=80=99t h=
ave alias template specializations: the definition cannot depend on the arg=
uments.)</div><div class=3D""><br class=3D""></div><div class=3D"">So, wher=
eas the line mentioning <font face=3D"Courier" class=3D"">Class&lt;int&gt;<=
/font> can inspect the identity of a particular class, the one mentioning <=
font face=3D"Courier" class=3D"">Alias&lt;int&gt;</font> will never be able=
 to observe anything but the&nbsp;<font face=3D"Courier" class=3D"">int</fo=
nt>&nbsp;produced by its substitution.</div></body></html>

<p></p>

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

--Apple-Mail=_80860199-9CCF-4039-8DE5-AED97501C5B5--

.