------=_Part_2145_22033325.1352590839316
Content-Type: text/plain; charset=ISO-8859-1



On Friday, November 9, 2012 12:54:53 AM UTC+1, masse....@gmail.com wrote:
>
> Interesting thread.
> I read the N3418, and this make me having some though. Here they are :
>
>
*5.2 We do not propose allowing instantiation of a non-generic lambda from
> a generic one*
> Take this generic function for example:
> []increment(&x) { x++; }
>
> Now I'd like to do :
> std::vector<int> v;
> //...
> std::for_each( begin(v), end(v), increment);
>
> But this won' work, because increment is a generic function and need to be
> instancied.
>
Wrong. It's not a *function*, it's a *function object*, the same as:
struct increment{
  template<class T>
  void operator()(T& x){ x++; }
};
And can as such be passed with just the name.

*5.4 Feature extension in the setting of the Concepts Proposal (n3351)*
> This makes me think about the problem with auto keyword wich tend to be
> required. Also, I' asking to myself "wouldn't the typename keyword make
> more sense here?"
>
No, it wouldn't. typename says that the identifier following it names a
type, which is not the case here.

*6 Further work*
> * variadic templates :*
> *
> if we define the min method like this :
> []min(typename x, typename y) { return x < y ? x : y; }
> []min(typename x, typename... args) { return min(x, min(args...); }
> we could then write something like this :
>
> int x,y,z;
> //...
> return min(x,y,z); //this would be resolved in : return min(x, min(y,z));
>
Ignoring the typename issue, variadic templates indeed seem to be missing
from the proposal.

--




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

<br><br>On Friday, November 9, 2012 12:54:53 AM UTC+1, masse....@gmail.com =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Interesting thread.=
<br></div><div>I read the N3418, and this make me having some though. Here =
they are :<br>&nbsp;</div></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div></div><div><b><u>5.2 We do not propose allowing instantiation=
 of a non-generic lambda from a generic one</u></b></div><div>Take this gen=
eric function for example:</div><div>[]increment(&amp;x) { x++; }</div><div=
><br></div><div>Now I'd like to do :&nbsp;</div><div>std::vector&lt;int&gt;=
 v;</div><div>//...</div><div>std::for_each( begin(v), end(v), increment);<=
/div><div><br></div><div>But this won' work, because&nbsp;increment is a ge=
neric function and need to be instancied.</div></blockquote><div>Wrong. It'=
s not a *function*, it's a *function object*, the same as:<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: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> increment</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"colo=
r: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">op=
erator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">){</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">++;</span><span style=3D"color: #000;" class=3D"s=
tyled-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><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div>And can as such be passed with just the name. <br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div><b><u>5.4 Feature exten=
sion in the setting of the Concepts Proposal (n3351)</u></b></div><div>This=
 makes me think about the problem with auto keyword wich tend to be require=
d. Also, I' asking to myself "wouldn't the typename keyword make more sense=
 here?"</div></blockquote><div>No, it wouldn't.<span style=3D"color: #008;"=
 class=3D"styled-by-prettify"><code> </code>typename</span><code class=3D"p=
rettyprint"></code> says that the identifier following it names a type, whi=
ch is not the case here.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div><u><b>6 Further work</b></u></div><div>* variadic templates :<=
u><b><br></b></u></div><div>if we define the min method like this :&nbsp;</=
div><div>[]min(typename x, typename y) { return x &lt; y ? x : y; }</div><d=
iv>[]min(typename x, typename... args) { return min(x, min(args...); }</div=
><div>we could then write something like this :</div><div><br></div><div>in=
t x,y,z;</div><div>//...</div><div>return min(x,y,z); //this would be resol=
ved in :&nbsp;return min(x, min(y,z));</div></blockquote><div>Ignoring the<=
span style=3D"color: #008;" class=3D"styled-by-prettify"><code> </code>type=
name</span><code class=3D"prettyprint"></code> issue, variadic templates in=
deed seem to be missing from the proposal.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2145_22033325.1352590839316--

.

------=_Part_2390_3120835.1352605957168
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:
>
>
>
> On Friday, November 9, 2012 12:54:53 AM UTC+1, masse....@gmail.com wrote:
>>
>> Interesting thread.
>> I read the N3418, and this make me having some though. Here they are :
>>
>>
> *5.2 We do not propose allowing instantiation of a non-generic lambda
>> from a generic one*
>> Take this generic function for example:
>> []increment(&x) { x++; }
>>
>> Now I'd like to do :
>> std::vector<int> v;
>> //...
>> std::for_each( begin(v), end(v), increment);
>>
>> But this won' work, because increment is a generic function and need to
>> be instancied.
>>
> Wrong. It's not a *function*, it's a *function object*, the same as:
> struct increment{
>   template<class T>
>   void operator()(T& x){ x++; }
> };
> And can as such be passed with just the name.
>
> *5.4 Feature extension in the setting of the Concepts Proposal (n3351)*
>> This makes me think about the problem with auto keyword wich tend to be
>> required. Also, I' asking to myself "wouldn't the typename keyword make
>> more sense here?"
>>
> No, it wouldn't. typename says that the identifier following it names a
> type, which is not the case here.
>
> *6 Further work*
>> * variadic templates :*
>> *
>> if we define the min method like this :
>> []min(typename x, typename y) { return x < y ? x : y; }
>> []min(typename x, typename... args) { return min(x, min(args...); }
>> we could then write something like this :
>>
>> int x,y,z;
>> //...
>> return min(x,y,z); //this would be resolved in : return min(x, min(y,z));
>>
> Ignoring the typename issue, variadic templates indeed seem to be missing
> from the proposal.
>

Nevermind, they're in there (as examples under 2.2). However, it seems not
to be explicitly mentioned that [](...vs){} (or [](auto... vs){}) is
allowed. Note that [](...){} can never be ambiguous, since unnamed
parameters are disallowed (note under 2.1) and as such will always be a
C-style variadic function.



--




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

On Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><br><br>On Friday, November 9, 2012 12:54:53 AM=
 UTC+1, <a>masse....@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>Interesting thread.<br></div><div>I read the N3418, and this mak=
e me having some though. Here they are :<br>&nbsp;</div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div></div><div><b><u>5.2 We do not propo=
se allowing instantiation of a non-generic lambda from a generic one</u></b=
></div><div>Take this generic function for example:</div><div>[]increment(&=
amp;x) { x++; }</div><div><br></div><div>Now I'd like to do :&nbsp;</div><d=
iv>std::vector&lt;int&gt; v;</div><div>//...</div><div>std::for_each( begin=
(v), end(v), increment);</div><div><br></div><div>But this won' work, becau=
se&nbsp;increment is a generic function and need to be instancied.</div></b=
lockquote><div>Wrong. It's not a *function*, it's a *function object*, the =
same as:<br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode><div><span style=3D"color:#008">struct</span><span style=3D"color:#000"=
> increment</span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>&nbsp; </span><span style=3D"color:#008">template</span><span styl=
e=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><span st=
yle=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span sty=
le=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">void</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">operator</span=
><span style=3D"color:#660">()(</span><span style=3D"color:#000">T</span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">){</span><span style=3D"color:#000"> x</span><span=
 style=3D"color:#660">++;</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">};</span><span style=3D"color:#000"><br></span></div></cod=
e></div>And can as such be passed with just the name. <br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div><b><u>5.4 Feature extension in the se=
tting of the Concepts Proposal (n3351)</u></b></div><div>This makes me thin=
k about the problem with auto keyword wich tend to be required. Also, I' as=
king to myself "wouldn't the typename keyword make more sense here?"</div><=
/blockquote><div>No, it wouldn't.<span style=3D"color:#008"><code> </code>t=
ypename</span><code></code> says that the identifier following it names a t=
ype, which is not the case here.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div><u><b>6 Further work</b></u></div><div>* variadic templates=
 :<u><b><br></b></u></div><div>if we define the min method like this :&nbsp=
;</div><div>[]min(typename x, typename y) { return x &lt; y ? x : y; }</div=
><div>[]min(typename x, typename... args) { return min(x, min(args...); }</=
div><div>we could then write something like this :</div><div><br></div><div=
>int x,y,z;</div><div>//...</div><div>return min(x,y,z); //this would be re=
solved in :&nbsp;return min(x, min(y,z));</div></blockquote><div>Ignoring t=
he<span style=3D"color:#008"><code> </code>typename</span><code></code> iss=
ue, variadic templates indeed seem to be missing from the proposal.</div></=
blockquote><div><br>Nevermind, they're in there (as examples under 2.2). Ho=
wever, it seems not to be explicitly mentioned that <span style=3D"color: #=
660;" class=3D"styled-by-prettify"><code></code>[](...</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">vs</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">){}</span><code class=3D"prettyprint"><=
/code> (or <span style=3D"color: #660;" class=3D"styled-by-prettify"><code>=
</code>[](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> vs</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">){}</span><code clas=
s=3D"prettyprint"></code>) is allowed. Note that <span style=3D"color: #660=
;" class=3D"styled-by-prettify"><code></code>[](...){}</span><code class=3D=
"prettyprint"></code> can never be ambiguous, since unnamed parameters are =
disallowed (note under 2.1) and as such will always be a C-style variadic f=
unction.<br><br><br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2390_3120835.1352605957168--

.

------=_Part_10_21400770.1352606046295
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:

> Ignoring the typename issue, variadic templates indeed seem to be missing
> from the proposal.
>

Nevermind, they're in there (as examples under 2.2). However, it seems not
to be explicitly mentioned (unless I overlooked something *again*) that
[](...vs){} (or [](auto... vs){}) is allowed. Note that [](...){} can never
be ambiguous, since unnamed parameters are disallowed (note under 2.1) and
as such will always be a C-style variadic function.

--




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

On Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>Ignoring the<span style=3D"color:#008"=
><code> </code>typename</span><code></code> issue, variadic templates indee=
d seem to be missing from the proposal.</div></blockquote><div><br>Nevermin=
d, they're in there (as examples under 2.2). However, it seems not to be ex=
plicitly mentioned (unless I overlooked something <i>again</i>) that <span =
style=3D"color:#660"><code></code>[](...</span><span style=3D"color:#000">v=
s</span><span style=3D"color:#660">){}</span><code></code> (or <span style=
=3D"color:#660"><code></code>[](</span><span style=3D"color:#008">auto</spa=
n><span style=3D"color:#660">...</span><span style=3D"color:#000"> vs</span=
><span style=3D"color:#660">){}</span><code></code>) is allowed. Note that =
<span style=3D"color:#660"><code></code>[](...){}</span><code></code>
 can never be ambiguous, since unnamed parameters are disallowed (note=20
under 2.1) and as such will always be a C-style variadic function. <br></di=
v>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_10_21400770.1352606046295--

.

------=_Part_1966_23673330.1352696246171
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Can you be more descriptive about what you mean by "doesn't work well" with=
=20
this example:

template <typename R>
auto fn (auto & a, R & d) { return a+d; }

I agree it looks a tad strange, but I'm not sure what wouldn't work about=
=20
this.  Once a parser knows it is dealing with a template, it would parse=20
the typename names and value names in the parameter list, and would=20
auto-generate a typename name for any 'auto' parameters in the function=20
signature.  When parsing the function body, all typenames will be known,=20
even if some are compiler-generated names.

As far as specialization goes, I did mention in the original post that it=
=20
would likely be quite difficult with this syntax, and have had a few more=
=20
thoughts since then.  This would not replace any existing syntax, so if you=
=20
need to specialize your template, you could always use the current=20
mechanism.  I know this limitation will be a big hurdle to getting this=20
idea standardized.  However, I believe that it would be possible, although=
=20
I don't have a very good idea of exactly how to go about it.  Here's one=20
thought, that I'm sure is rife with overload/template resolution problems:

template <typename T, typename U>
int old_way (T & t, U & u)
{ return t + u; }

template <typename U>
int old_way<double, U> (double & t, U & u)
{ return static_cast<int>(t+1) + u; }

template <typename T>
int old_way<T, double> (T & t, double & u)
{ return t + static_cast<int>(u-1); }

template <>
int old_way<double, double> (double & t, double & u)
{ return static_cast<int>(t+1) + static_cast<int>(u-1); }


template int new_way (auto & t, auto & u)
{ return t + u; }

// template keyword puts parser in template mode
// parser sees new_way is existing template, tries specialization with two=
=20
auto-generated types
// sees actual type in first position, partially specializes on that.
template int new_way (double & t, auto & u)
{ return static_cast<int>(t+1) + u; }

// template keyword puts parser in template mode
// parser sees new_way is existing template, tries specialization with two=
=20
auto-generated types
// sees actual type in second position, partially specializes on that.
template int new_way (auto & t, double & u)
{ return t + static_cast<int>(u-1); }

// template keyword puts parser in template mode
// parser sees new_way is existing template, tries specialization with two=
=20
auto-generated types
// sees actual types in first and second position, fully specializes on=20
that.
// *** Interestingly enough, this looks almost like a regular function, all=
=20
except for the 'template'
// keyword.  I'm not sure how this all would interact with overload=20
resolution
template int old_way (double & t, double & u)
{ return static_cast<int>(t+1) + static_cast<int>(u-1); }

I could see some issues if the signatures of the specializations were=20
different, but I'm not familiar enough with the rules to say what those=20
issues would be.

Thanks for the feedback!  Unless anyone is willing to pitch in and champion=
=20
this, it will take me a while to get it all down pat anyhow.


On Thursday, November 8, 2012 3:48:32 PM UTC-6, toma...@gmail.com wrote:
>
>
>
> W dniu czwartek, 8 listopada 2012 06:08:18 UTC+1 u=BFytkownik=20
> michael...@gmail.com napisa=B3:
>>
>> Templates can sometimes be quite verbose...
>>
>> template <typename Fn, typename T1, typename T2, typename T3>
>> auto reverse_caller (Fn && fn, T1 && t1, T2 && t2, T3 && t3) ->=20
>> decltype(fn(t3, t2, t1)
>> {
>>     return fn(t3, t2, t1);
>> }
>>
>> There is a lot of type information that is never used beyond declaring=
=20
>> the function parameters.  It would be much nicer if we could write this=
=20
>> instead
>>
>> template
>> auto reverse_caller (auto && fn, auto && t1, auto && t2, auto && t3) ->=
=20
>> decltype(fn(t3, t2, t1)
>> {
>>     return fn(t3, t2, t1);
>> }
>>
> This syntax dosen't work well if somone want mix the template parameters=
=20
> with named type and deducted type. Example:
> template<typename R>
> auto fn(auto &a, R& d) { return a+d; }
> And for my opinion will conflict with explicit function template=20
> specjalization. Maybe the syntax:
> template<...> /* some unamed parametrs */
> auto fn(auto &a, auto& b) { return a + b; }
>
> And for the second example
> template<typename R, ...>
> auto fn(auto &a, R& d) { return a+d; }
> =20
>
>> This would be simplified even more if/when the normal-function return=20
>> type deduction makes it into the language.  It wouldn't allow for=20
>> specialization or for type defaults, but it would still be a useful synt=
ax=20
>> for many usages of templates.  We could also consider removing the templ=
ate=20
>> keyword here, but I feel that might be too asking too much from=20
>> implementers as they would have to consider every function declaration a=
s a=20
>> possible template until they discovered that there were no type-deduced=
=20
>> parameters in the parameter list.
>>
>> Furthermore, we could also a similar technique for deducing template=20
>> value parameters by throwing the constexpr keyword in there (unless this=
 is=20
>> already possible???)
>>
>> template <int Base>
>> int calculate (int val)
>> { return someOperation(Base, val); }
>>
>> calculate<10>(5); // Usage... how strange.
>>
>> versus
>>
>> template
>> int calculate (constexpr int base, int val)
>> { return someOperation(base, val); }
>>
>> calculate(10, 5); // This looks normal!
>>
>> Note that the latter could possibly be implemented as a=20
>> constexpr-function but that may not be possible, depending on the=20
>> definition of someOperation and might allow  some runtime computation th=
at=20
>> wasn't intended.  It becomes even stronger when you combine the two=20
>> approaches
>>
>> template <typename T, T Value>
>> T incr () { return Value+1; }
>>
>> incr<int, 5>(); // Again, hard to parse for humans
>>
>> versus
>>
>> template
>> auto incr (constexpr auto v) -> decltype(v)
>> { return v+1; }
>>
>> incr(5); // Looks like a normal function call!
>>
>> So, I'm certain that there are dozens of horrible things that I have not=
=20
>> considered yet, but if this shows promise, I would love to turn this int=
o a=20
>> proposal.  Please, show no mercy... ;-)
>>
>

--=20




------=_Part_1966_23673330.1352696246171
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Can you be more descriptive about what you mean by "doesn't work well" with=
 this example:<div><br><div><div><font face=3D"courier new, monospace">temp=
late &lt;typename R&gt;</font></div><div><font face=3D"courier new, monospa=
ce">auto fn (auto &amp; a, R &amp; d)&nbsp;</font><span style=3D"font-famil=
y: 'courier new', monospace; ">{&nbsp;</span><span style=3D"font-family: 'c=
ourier new', monospace; ">return a+d;&nbsp;</span><span style=3D"font-famil=
y: 'courier new', monospace; ">}</span></div></div><div><br></div><div>I ag=
ree it looks a tad strange, but I'm not sure what wouldn't work about this.=
 &nbsp;Once a parser knows it is dealing with a template, it would parse th=
e typename names and value names in the parameter list, and would auto-gene=
rate a typename name for any 'auto' parameters in the function signature. &=
nbsp;When parsing the function body, all typenames will be known, even if s=
ome are compiler-generated names.</div><div><br></div><div>As far as specia=
lization goes, I did mention in the original post that it would likely be q=
uite difficult with this syntax, and have had a few more thoughts since the=
n. &nbsp;This would not replace any existing syntax, so if you need to spec=
ialize your template, you could always use the current mechanism. &nbsp;I k=
now this limitation will be a big hurdle to getting this idea standardized.=
 &nbsp;However, I believe that it would be possible, although I don't have =
a very good idea of exactly how to go about it. &nbsp;Here's one thought, t=
hat I'm sure is rife with overload/template resolution problems:</div><div>=
<br></div><div><div><font face=3D"courier new, monospace">template &lt;type=
name T, typename U&gt;</font></div><div><font face=3D"courier new, monospac=
e">int old_way (T &amp; t, U &amp; u)</font></div><div><span style=3D"font-=
family: 'courier new', monospace; ">{&nbsp;</span><span style=3D"font-famil=
y: 'courier new', monospace; ">return t + u;&nbsp;</span><span style=3D"fon=
t-family: 'courier new', monospace; ">}</span></div><div><span style=3D"fon=
t-family: 'courier new', monospace; "><br></span></div><div><span style=3D"=
font-family: 'courier new', monospace; ">template &lt;typename U&gt;</span>=
</div><div><span style=3D"font-family: 'courier new', monospace; ">int old_=
way&lt;double, U&gt; (double &amp; t, U &amp; u)</span></div><div><span sty=
le=3D"font-family: 'courier new', monospace; ">{ return static_cast&lt;int&=
gt;(t+1) + u; }</span></div><div><span style=3D"font-family: 'courier new',=
 monospace; "><br></span></div><div><div><span style=3D"font-family: 'couri=
er new', monospace; ">template &lt;typename T&gt;</span></div><div><span st=
yle=3D"font-family: 'courier new', monospace; ">int old_way&lt;T, double&gt=
; (T &amp; t, double &amp; u)</span></div><div><span style=3D"font-family: =
'courier new', monospace; ">{ return t +&nbsp;</span><span style=3D"font-fa=
mily: 'courier new', monospace; ">static_cast&lt;int&gt;(</span><span style=
=3D"font-family: 'courier new', monospace; ">u-1); }</span></div></div><div=
><span style=3D"font-family: 'courier new', monospace; "><br></span></div><=
div><div><span style=3D"font-family: 'courier new', monospace; ">template &=
lt;&gt;</span></div><div><span style=3D"font-family: 'courier new', monospa=
ce; ">int old_way&lt;double, double&gt; (double &amp; t, double &amp; u)</s=
pan></div><div><span style=3D"font-family: 'courier new', monospace; ">{ re=
turn&nbsp;</span><span style=3D"font-family: 'courier new', monospace; ">st=
atic_cast&lt;int&gt;(</span><span style=3D"font-family: 'courier new', mono=
space; ">t+1) +&nbsp;</span><span style=3D"font-family: 'courier new', mono=
space; ">static_cast&lt;int&gt;(</span><span style=3D"font-family: 'courier=
 new', monospace; ">u-1); }</span></div></div><div><span style=3D"font-fami=
ly: 'courier new', monospace; "><br></span></div><div><span style=3D"font-f=
amily: 'courier new', monospace; "><br></span></div><div><div><font face=3D=
"courier new, monospace">template&nbsp;</font><span style=3D"font-family: '=
courier new', monospace; ">int new_way (auto &amp; t, auto &amp; u)</span><=
/div><div><span style=3D"font-family: 'courier new', monospace; ">{&nbsp;</=
span><span style=3D"font-family: 'courier new', monospace; ">return t + u;&=
nbsp;</span><span style=3D"font-family: 'courier new', monospace; ">}</span=
></div><div><span style=3D"font-family: 'courier new', monospace; "><br></s=
pan></div><div><span style=3D"font-family: 'courier new', monospace; ">// t=
emplate keyword puts parser in template mode</span></div><div><span style=
=3D"font-family: 'courier new', monospace; ">// parser sees new_way is exis=
ting template, tries specialization with two auto-generated types</span></d=
iv><div><span style=3D"font-family: 'courier new', monospace; ">// sees act=
ual type in first position, partially specializes on that.</span></div><div=
><span style=3D"font-family: 'courier new', monospace; ">template&nbsp;</sp=
an><span style=3D"font-family: 'courier new', monospace; ">int new_way (dou=
ble &amp; t, auto &amp; u)</span></div><div><span style=3D"font-family: 'co=
urier new', monospace; ">{ return static_cast&lt;int&gt;(t+1) + u; }</span>=
</div><div><span style=3D"font-family: 'courier new', monospace; "><br></sp=
an></div><div><div><span style=3D"font-family: 'courier new', monospace; ">=
// template keyword puts parser in template mode</span></div><div><span sty=
le=3D"font-family: 'courier new', monospace; ">// parser sees new_way is ex=
isting template, tries specialization with two auto-generated types</span><=
/div><div><span style=3D"font-family: 'courier new', monospace; ">// sees a=
ctual type in second position, partially specializes on that.</span></div><=
/div><div><div><span style=3D"font-family: 'courier new', monospace; ">temp=
late&nbsp;</span><span style=3D"font-family: 'courier new', monospace; ">in=
t new_way (auto &amp; t, double &amp; u)</span></div><div><span style=3D"fo=
nt-family: 'courier new', monospace; ">{ return t +&nbsp;</span><span style=
=3D"font-family: 'courier new', monospace; ">static_cast&lt;int&gt;(</span>=
<span style=3D"font-family: 'courier new', monospace; ">u-1); }</span></div=
></div><div><span style=3D"font-family: 'courier new', monospace; "><br></s=
pan></div><div><div><span style=3D"font-family: 'courier new', monospace; "=
>// template keyword puts parser in template mode</span></div><div><span st=
yle=3D"font-family: 'courier new', monospace; ">// parser sees new_way is e=
xisting template, tries specialization with two auto-generated types</span>=
</div><div><span style=3D"font-family: 'courier new', monospace; ">// sees =
actual types in first and second position, fully specializes on that.</span=
></div></div><div><span style=3D"font-family: 'courier new', monospace; ">/=
/ *** Interestingly enough, this looks almost like a regular function, all =
except for the 'template'</span></div><div><span style=3D"font-family: 'cou=
rier new', monospace; ">// keyword. &nbsp;I'm not sure how this all would i=
nteract with overload resolution</span></div><div><div><span style=3D"font-=
family: 'courier new', monospace; ">template&nbsp;</span><span style=3D"fon=
t-family: 'courier new', monospace; ">int old_way (double &amp; t, double &=
amp; u)</span></div><div><span style=3D"font-family: 'courier new', monospa=
ce; ">{ return&nbsp;</span><span style=3D"font-family: 'courier new', monos=
pace; ">static_cast&lt;int&gt;(</span><span style=3D"font-family: 'courier =
new', monospace; ">t+1) +&nbsp;</span><span style=3D"font-family: 'courier =
new', monospace; ">static_cast&lt;int&gt;(</span><span style=3D"font-family=
: 'courier new', monospace; ">u-1); }</span></div></div></div><div><br></di=
v><div>I could see some issues if the signatures of the specializations wer=
e different, but I'm not familiar enough with the rules to say what those i=
ssues would be.</div><div><br></div>Thanks for the feedback! &nbsp;Unless a=
nyone is willing to pitch in and champion this, it will take me a while to =
get it all down pat anyhow.</div><div><br></div><div><br>On Thursday, Novem=
ber 8, 2012 3:48:32 PM UTC-6, toma...@gmail.com wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><br><br>W dniu czwartek, 8 listopada 2012 06:08:18 =
UTC+1 u=BFytkownik <a>michael...@gmail.com</a> napisa=B3:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Templates can sometimes be quite verbose...<div><br>=
</div><div><font face=3D"courier new, monospace">template &lt;typename Fn, =
typename T1, typename T2, typename T3&gt;</font></div><div><font face=3D"co=
urier new, monospace">auto reverse_caller (Fn &amp;&amp; fn, T1 &amp;&amp; =
t1, T2 &amp;&amp; t2, T3 &amp;&amp; t3) -&gt; decltype(fn(t3, t2, t1)</font=
></div><div><font face=3D"courier new, monospace">{</font></div><div><font =
face=3D"courier new, monospace">&nbsp; &nbsp; return fn(t3, t2, t1);</font>=
</div><div><font face=3D"courier new, monospace">}</font></div><div><br></d=
iv><div>There is a lot of type information that is never used beyond declar=
ing the function parameters. &nbsp;It would be much nicer if we could write=
 this instead</div><div><br></div><div><font face=3D"courier new, monospace=
">template</font></div><div><font face=3D"courier new, monospace">auto reve=
rse_caller (auto &amp;&amp; fn, auto &amp;&amp; t1, auto &amp;&amp; t2, aut=
o &amp;&amp; t3) -&gt; decltype(fn(t3, t2, t1)</font></div><div><font face=
=3D"courier new, monospace">{</font></div><div><font face=3D"courier new, m=
onospace">&nbsp; &nbsp; return fn(t3, t2, t1);</font></div><div><font face=
=3D"courier new, monospace">}</font></div></blockquote><div>This syntax dos=
en't work well if somone want mix the template parameters with named type a=
nd deducted type. Example:<br>template&lt;typename R&gt;<br>auto fn(auto &a=
mp;a, R&amp; d) { return a+d; }<br>And for my opinion will conflict with ex=
plicit function template specjalization. Maybe the syntax:<br>template&lt;.=
...&gt; /* some unamed parametrs */<br>auto fn(auto &amp;a, auto&amp; b) { r=
eturn a + b; }<br><br>And for the second example<br>template&lt;typename R,=
 ...&gt;<br>auto fn(auto &amp;a, R&amp; d) { return a+d;  }<div><font face=
=3D"courier new, monospace"></font></div>&nbsp;<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>This would be simplified even more if/when the =
normal-function return type deduction makes it into the language. &nbsp;It =
wouldn't allow for specialization or for type defaults, but it would still =
be a useful syntax for many usages of templates. &nbsp;We could also consid=
er removing the template keyword here, but I feel that might be too asking =
too much from implementers as they would have to consider every function de=
claration as a possible template until they discovered that there were no t=
ype-deduced parameters in the parameter list.</div><div><br></div><div>Furt=
hermore, we could also a similar technique for deducing template value para=
meters by throwing the constexpr keyword in there (unless this is already p=
ossible???)</div><div><br></div><div><font face=3D"courier new, monospace">=
template &lt;int Base&gt;</font></div><div><font face=3D"courier new, monos=
pace">int calculate (int val)</font></div><div><font face=3D"courier new, m=
onospace">{ return someOperation(Base, val); }</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">calculate&lt;10&gt;(5); // Usage... how strange.</font></div><=
div><br></div><div>versus</div><div><br></div><div><font face=3D"courier ne=
w, monospace">template</font></div><div><font face=3D"courier new, monospac=
e">int calculate (constexpr int base, int val)</font></div><div><font face=
=3D"courier new, monospace">{ return someOperation(base, val); }</font></di=
v><div><font face=3D"courier new, monospace"><br></font></div><div><font fa=
ce=3D"courier new, monospace">calculate(10, 5); // This looks normal!</font=
></div><div><br></div><div>Note that the latter could possibly be implement=
ed as a constexpr-function but that may not be possible, depending on the d=
efinition of someOperation and might allow &nbsp;some runtime computation t=
hat wasn't intended. &nbsp;It becomes even stronger when you combine the tw=
o approaches</div><div><br></div><div><div><font face=3D"courier new, monos=
pace">template &lt;typename T, T Value&gt;</font></div><div><font face=3D"c=
ourier new, monospace">T incr () { return Value+1; }</font></div></div><div=
><font face=3D"courier new, monospace"><br></font></div><div><font face=3D"=
courier new, monospace">incr&lt;int, 5&gt;(); // Again, hard to parse for h=
umans</font></div><div><br></div><div>versus</div><div><br></div><div><font=
 face=3D"courier new, monospace">template</font></div><div><font face=3D"co=
urier new, monospace">auto incr (constexpr auto v) -&gt; decltype(v)</font>=
</div><div><font face=3D"courier new, monospace">{ return v+1; }</font></di=
v><div><font face=3D"courier new, monospace"><br></font></div><div><font fa=
ce=3D"courier new, monospace">incr(5); // Looks like a normal function call=
!</font></div><div><br></div><div>So, I'm certain that there are dozens of =
horrible things that I have not considered yet, but if this shows promise, =
I would love to turn this into a proposal. &nbsp;Please, show no mercy... ;=
-)</div></blockquote></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1966_23673330.1352696246171--

.

------=_Part_1115_31090241.1352696430687
Content-Type: text/plain; charset=ISO-8859-1

I'm unclear on how this relates to my proposal exactly.  Perhaps you or I
(or both) are getting confused?

On Saturday, November 10, 2012 9:54:06 PM UTC-6, Xeo wrote:
>
> On Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:
>
>> Ignoring the typename issue, variadic templates indeed seem to be
>> missing from the proposal.
>>
>
> Nevermind, they're in there (as examples under 2.2). However, it seems not
> to be explicitly mentioned (unless I overlooked something *again*) that
> [](...vs){} (or [](auto... vs){}) is allowed. Note that [](...){} can
> never be ambiguous, since unnamed parameters are disallowed (note under
> 2.1) and as such will always be a C-style variadic function.
>

--




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

I'm unclear on how this relates to my proposal exactly.  Perhaps you o=
r I (or both) are getting confused?<br><br>On Saturday, November 10, 2012 9=
:54:06 PM UTC-6, Xeo wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
Sunday, November 11, 2012 12:40:39 AM UTC+1, Xeo wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>Ignoring the<span style=3D"color:#008"><code> =
</code>typename</span><code></code> issue, variadic templates indeed seem t=
o be missing from the proposal.</div></blockquote><div><br>Nevermind, they'=
re in there (as examples under 2.2). However, it seems not to be explicitly=
 mentioned (unless I overlooked something <i>again</i>) that <span style=3D=
"color:#660"><code></code>[](...</span><span style=3D"color:#000">vs</span>=
<span style=3D"color:#660">){}</span><code></code> (or <span style=3D"color=
:#660"><code></code>[](</span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#660">...</span><span style=3D"color:#000"> vs</span><span st=
yle=3D"color:#660">){}</span><code></code>) is allowed. Note that <span sty=
le=3D"color:#660"><code></code>[](...){}</span><code></code>
 can never be ambiguous, since unnamed parameters are disallowed (note=20
under 2.1) and as such will always be a C-style variadic function. <br></di=
v></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1115_31090241.1352696430687--

.

------=_Part_626_29412283.1352713890857
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

W dniu poniedzia=B3ek, 12 listopada 2012 05:57:26 UTC+1 u=BFytkownik=20
michael...@gmail.com napisa=B3:
>
> Can you be more descriptive about what you mean by "doesn't work well"=20
> with this example:
>
> template <typename R>
> auto fn (auto & a, R & d) { return a+d; }
>
> I agree it looks a tad strange, but I'm not sure what wouldn't work about=
=20
> this.  Once a parser knows it is dealing with a template, it would parse=
=20
> the typename names and value names in the parameter list, and would=20
> auto-generate a typename name for any 'auto' parameters in the function=
=20
> signature.  When parsing the function body, all typenames will be known,=
=20
> even if some are compiler-generated names.
>
> As far as specialization goes, I did mention in the original post that it=
=20
> would likely be quite difficult with this syntax, and have had a few more=
=20
> thoughts since then.  This would not replace any existing syntax, so if y=
ou=20
> need to specialize your template, you could always use the current=20
> mechanism.  I know this limitation will be a big hurdle to getting this=
=20
> idea standardized.  However, I believe that it would be possible, althoug=
h=20
> I don't have a very good idea of exactly how to go about it.  Here's one=
=20
> thought, that I'm sure is rife with overload/template resolution problems=
:
>
> template <typename T, typename U>
> int old_way (T & t, U & u)
> { return t + u; }
>
> template <typename U>
> int old_way<double, U> (double & t, U & u)
> { return static_cast<int>(t+1) + u; }
>
> template <typename T>
> int old_way<T, double> (T & t, double & u)
> { return t + static_cast<int>(u-1); }
>
> template <>
> int old_way<double, double> (double & t, double & u)
> { return static_cast<int>(t+1) + static_cast<int>(u-1); }
>
>  template <>
 int old_way<double, double> (double & t, double & u); //declaration of=20
explicit specialization

 template
 int old_way<double, double> (double & t, double & u); //explicit=20
instantiation of template function


template int new_way (auto & t, auto & u)
> { return t + u; }
>
> // template keyword puts parser in template mode
> // parser sees new_way is existing template, tries specialization with tw=
o=20
> auto-generated types
> // sees actual type in first position, partially specializes on that.
> template int new_way (double & t, auto & u)
> { return static_cast<int>(t+1) + u; }
>
> // template keyword puts parser in template mode
> // parser sees new_way is existing template, tries specialization with tw=
o=20
> auto-generated types
> // sees actual type in second position, partially specializes on that.
> template int new_way (auto & t, double & u)
> { return t + static_cast<int>(u-1); }
>
> // template keyword puts parser in template mode
> // parser sees new_way is existing template, tries specialization with tw=
o=20
> auto-generated types
> // sees actual types in first and second position, fully specializes on=
=20
> that.
> // *** Interestingly enough, this looks almost like a regular function,=
=20
> all except for the 'template'
> // keyword.  I'm not sure how this all would interact with overload=20
> resolution
> template int old_way (double & t, double & u)
> { return static_cast<int>(t+1) + static_cast<int>(u-1); }
>
> template int new_way (double & t, double & u); //amigious, may be one of=
=20
the following:
                                               // declaration of explicit=
=20
specialization (old way template<> old_way) without definition;
                                               // explicit instantiation of=
=20
template function (old way template old_way)

=20

> I could see some issues if the signatures of the specializations were=20
> different, but I'm not familiar enough with the rules to say what those=
=20
> issues would be.
>
> Thanks for the feedback!  Unless anyone is willing to pitch in and=20
> champion this, it will take me a while to get it all down pat anyhow.
>
> Also as the deduction for normal function is adopted to standard, you=20
should consider if the declartion:

auto f(auto a, auto b);

Would be interpreted as:
template<typename R, typename A, typename B>
R f(A a, B b); //auto in return type represents just another template=20
argument.

Or:
template<typename A, typename B>
auto f(A a, B b); //auto is used for enabling deduction for return type.

> On Thursday, November 8, 2012 3:48:32 PM UTC-6, toma...@gmail.com wrote:
>>
>>
>>
>> W dniu czwartek, 8 listopada 2012 06:08:18 UTC+1 u=BFytkownik=20
>> michael...@gmail.com napisa=B3:
>>>
>>> Templates can sometimes be quite verbose...
>>>
>>> template <typename Fn, typename T1, typename T2, typename T3>
>>> auto reverse_caller (Fn && fn, T1 && t1, T2 && t2, T3 && t3) ->=20
>>> decltype(fn(t3, t2, t1)
>>> {
>>>     return fn(t3, t2, t1);
>>> }
>>>
>>> There is a lot of type information that is never used beyond declaring=
=20
>>> the function parameters.  It would be much nicer if we could write this=
=20
>>> instead
>>>
>>> template
>>> auto reverse_caller (auto && fn, auto && t1, auto && t2, auto && t3) ->=
=20
>>> decltype(fn(t3, t2, t1)
>>> {
>>>     return fn(t3, t2, t1);
>>> }
>>>
>> This syntax dosen't work well if somone want mix the template parameters=
=20
>> with named type and deducted type. Example:
>> template<typename R>
>> auto fn(auto &a, R& d) { return a+d; }
>> And for my opinion will conflict with explicit function template=20
>> specjalization. Maybe the syntax:
>> template<...> /* some unamed parametrs */
>> auto fn(auto &a, auto& b) { return a + b; }
>>
>> And for the second example
>> template<typename R, ...>
>> auto fn(auto &a, R& d) { return a+d; }
>> =20
>>
>>> This would be simplified even more if/when the normal-function return=
=20
>>> type deduction makes it into the language.  It wouldn't allow for=20
>>> specialization or for type defaults, but it would still be a useful syn=
tax=20
>>> for many usages of templates.  We could also consider removing the temp=
late=20
>>> keyword here, but I feel that might be too asking too much from=20
>>> implementers as they would have to consider every function declaration =
as a=20
>>> possible template until they discovered that there were no type-deduced=
=20
>>> parameters in the parameter list.
>>>
>>> Furthermore, we could also a similar technique for deducing template=20
>>> value parameters by throwing the constexpr keyword in there (unless thi=
s is=20
>>> already possible???)
>>>
>>> template <int Base>
>>> int calculate (int val)
>>> { return someOperation(Base, val); }
>>>
>>> calculate<10>(5); // Usage... how strange.
>>>
>>> versus
>>>
>>> template
>>> int calculate (constexpr int base, int val)
>>> { return someOperation(base, val); }
>>>
>>> calculate(10, 5); // This looks normal!
>>>
>>> Note that the latter could possibly be implemented as a=20
>>> constexpr-function but that may not be possible, depending on the=20
>>> definition of someOperation and might allow  some runtime computation t=
hat=20
>>> wasn't intended.  It becomes even stronger when you combine the two=20
>>> approaches
>>>
>>> template <typename T, T Value>
>>> T incr () { return Value+1; }
>>>
>>> incr<int, 5>(); // Again, hard to parse for humans
>>>
>>> versus
>>>
>>> template
>>> auto incr (constexpr auto v) -> decltype(v)
>>> { return v+1; }
>>>
>>> incr(5); // Looks like a normal function call!
>>>
>>> So, I'm certain that there are dozens of horrible things that I have no=
t=20
>>> considered yet, but if this shows promise, I would love to turn this in=
to a=20
>>> proposal.  Please, show no mercy... ;-)
>>>
>>

--=20




------=_Part_626_29412283.1352713890857
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

W dniu poniedzia=B3ek, 12 listopada 2012 05:57:26 UTC+1 u=BFytkownik michae=
l...@gmail.com napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Can y=
ou be more descriptive about what you mean by "doesn't work well" with this=
 example:<div><br><div><div><font face=3D"courier new, monospace">template =
&lt;typename R&gt;</font></div><div><font face=3D"courier new, monospace">a=
uto fn (auto &amp; a, R &amp; d)&nbsp;</font><span style=3D"font-family:'co=
urier new',monospace">{&nbsp;</span><span style=3D"font-family:'courier new=
',monospace">return a+d;&nbsp;</span><span style=3D"font-family:'courier ne=
w',monospace">}</span></div></div><div><br></div><div>I agree it looks a ta=
d strange, but I'm not sure what wouldn't work about this. &nbsp;Once a par=
ser knows it is dealing with a template, it would parse the typename names =
and value names in the parameter list, and would auto-generate a typename n=
ame for any 'auto' parameters in the function signature. &nbsp;When parsing=
 the function body, all typenames will be known, even if some are compiler-=
generated names.</div><div><br></div><div>As far as specialization goes, I =
did mention in the original post that it would likely be quite difficult wi=
th this syntax, and have had a few more thoughts since then. &nbsp;This wou=
ld not replace any existing syntax, so if you need to specialize your templ=
ate, you could always use the current mechanism. &nbsp;I know this limitati=
on will be a big hurdle to getting this idea standardized. &nbsp;However, I=
 believe that it would be possible, although I don't have a very good idea =
of exactly how to go about it. &nbsp;Here's one thought, that I'm sure is r=
ife with overload/template resolution problems:</div><div><br></div><div><d=
iv><font face=3D"courier new, monospace">template &lt;typename T, typename =
U&gt;</font></div><div><font face=3D"courier new, monospace">int old_way (T=
 &amp; t, U &amp; u)</font></div><div><span style=3D"font-family:'courier n=
ew',monospace">{&nbsp;</span><span style=3D"font-family:'courier new',monos=
pace">return t + u;&nbsp;</span><span style=3D"font-family:'courier new',mo=
nospace">}</span></div><div><span style=3D"font-family:'courier new',monosp=
ace"><br></span></div><div><span style=3D"font-family:'courier new',monospa=
ce">template &lt;typename U&gt;</span></div><div><span style=3D"font-family=
:'courier new',monospace">int old_way&lt;double, U&gt; (double &amp; t, U &=
amp; u)</span></div><div><span style=3D"font-family:'courier new',monospace=
">{ return static_cast&lt;int&gt;(t+1) + u; }</span></div><div><span style=
=3D"font-family:'courier new',monospace"><br></span></div><div><div><span s=
tyle=3D"font-family:'courier new',monospace">template &lt;typename T&gt;</s=
pan></div><div><span style=3D"font-family:'courier new',monospace">int old_=
way&lt;T, double&gt; (T &amp; t, double &amp; u)</span></div><div><span sty=
le=3D"font-family:'courier new',monospace">{ return t +&nbsp;</span><span s=
tyle=3D"font-family:'courier new',monospace">static_cast&lt;int&gt;(</span>=
<span style=3D"font-family:'courier new',monospace">u-1); }</span></div></d=
iv><div><span style=3D"font-family:'courier new',monospace"><br></span></di=
v><div><div><span style=3D"font-family:'courier new',monospace">template &l=
t;&gt;</span></div><div><span style=3D"font-family:'courier new',monospace"=
>int old_way&lt;double, double&gt; (double &amp; t, double &amp; u)</span><=
/div><div><span style=3D"font-family:'courier new',monospace">{ return&nbsp=
;</span><span style=3D"font-family:'courier new',monospace">static_cast&lt;=
int&gt;(</span><span style=3D"font-family:'courier new',monospace">t+1) +&n=
bsp;</span><span style=3D"font-family:'courier new',monospace">static_cast&=
lt;int&gt;(</span><span style=3D"font-family:'courier new',monospace">u-1);=
 }</span></div></div><div><span style=3D"font-family:'courier new',monospac=
e"><br></span></div></div></div></blockquote><div>&nbsp;<span style=3D"font=
-family:'courier new',monospace">template &lt;&gt;</span><br>&nbsp;<span st=
yle=3D"font-family:'courier new',monospace">int old_way&lt;double, double&g=
t; (double &amp; t, double &amp; u); //</span>declaration of explicit speci=
alization<br><br>&nbsp;<span style=3D"font-family:'courier new',monospace">=
template</span><br>&nbsp;<span style=3D"font-family:'courier new',monospace=
">int old_way&lt;double, double&gt; (double &amp; t, double &amp; u); //</s=
pan>explicit instantiation of template function<br><br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><div><div><span style=3D"font-famil=
y:'courier new',monospace"></span></div><div><div><font face=3D"courier new=
, monospace">template&nbsp;</font><span style=3D"font-family:'courier new',=
monospace">int new_way (auto &amp; t, auto &amp; u)</span></div><div><span =
style=3D"font-family:'courier new',monospace">{&nbsp;</span><span style=3D"=
font-family:'courier new',monospace">return t + u;&nbsp;</span><span style=
=3D"font-family:'courier new',monospace">}</span></div><div><span style=3D"=
font-family:'courier new',monospace"><br></span></div><div><span style=3D"f=
ont-family:'courier new',monospace">// template keyword puts parser in temp=
late mode</span></div><div><span style=3D"font-family:'courier new',monospa=
ce">// parser sees new_way is existing template, tries specialization with =
two auto-generated types</span></div><div><span style=3D"font-family:'couri=
er new',monospace">// sees actual type in first position, partially special=
izes on that.</span></div><div><span style=3D"font-family:'courier new',mon=
ospace">template&nbsp;</span><span style=3D"font-family:'courier new',monos=
pace">int new_way (double &amp; t, auto &amp; u)</span></div><div><span sty=
le=3D"font-family:'courier new',monospace">{ return static_cast&lt;int&gt;(=
t+1) + u; }</span></div><div><span style=3D"font-family:'courier new',monos=
pace"><br></span></div><div><div><span style=3D"font-family:'courier new',m=
onospace">// template keyword puts parser in template mode</span></div><div=
><span style=3D"font-family:'courier new',monospace">// parser sees new_way=
 is existing template, tries specialization with two auto-generated types</=
span></div><div><span style=3D"font-family:'courier new',monospace">// sees=
 actual type in second position, partially specializes on that.</span></div=
></div><div><div><span style=3D"font-family:'courier new',monospace">templa=
te&nbsp;</span><span style=3D"font-family:'courier new',monospace">int new_=
way (auto &amp; t, double &amp; u)</span></div><div><span style=3D"font-fam=
ily:'courier new',monospace">{ return t +&nbsp;</span><span style=3D"font-f=
amily:'courier new',monospace">static_cast&lt;int&gt;(</span><span style=3D=
"font-family:'courier new',monospace">u-1); }</span></div></div><div><span =
style=3D"font-family:'courier new',monospace"><br></span></div><div><div><s=
pan style=3D"font-family:'courier new',monospace">// template keyword puts =
parser in template mode</span></div><div><span style=3D"font-family:'courie=
r new',monospace">// parser sees new_way is existing template, tries specia=
lization with two auto-generated types</span></div><div><span style=3D"font=
-family:'courier new',monospace">// sees actual types in first and second p=
osition, fully specializes on that.</span></div></div><div><span style=3D"f=
ont-family:'courier new',monospace">// *** Interestingly enough, this looks=
 almost like a regular function, all except for the 'template'</span></div>=
<div><span style=3D"font-family:'courier new',monospace">// keyword. &nbsp;=
I'm not sure how this all would interact with overload resolution</span></d=
iv><div><div><span style=3D"font-family:'courier new',monospace">template&n=
bsp;</span><span style=3D"font-family:'courier new',monospace">int old_way =
(double &amp; t, double &amp; u)</span></div><div><span style=3D"font-famil=
y:'courier new',monospace">{ return&nbsp;</span><span style=3D"font-family:=
'courier new',monospace">static_cast&lt;int&gt;(</span><span style=3D"font-=
family:'courier new',monospace">t+1) +&nbsp;</span><span style=3D"font-fami=
ly:'courier new',monospace">static_cast&lt;int&gt;(</span><span style=3D"fo=
nt-family:'courier new',monospace">u-1); }</span></div></div></div><div><br=
></div></div></div></blockquote><div><div><span style=3D"font-family:'couri=
er new',monospace">template&nbsp;</span><span style=3D"font-family:'courier=
 new',monospace">int new_way (double &amp; t, double &amp; u); //amigious, =
may be one of the following:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; // declaration of explicit specialization (old way template&lt;&gt=
; old_way) without definition;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; // explicit instantiation of template function (old way template=
 old_way)<br></span></div><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><div><div></div><div>I could see some issues if the signat=
ures of the specializations were different, but I'm not familiar enough wit=
h the rules to say what those issues would be.</div><div><br></div>Thanks f=
or the feedback! &nbsp;Unless anyone is willing to pitch in and champion th=
is, it will take me a while to get it all down pat anyhow.</div><div><br></=
div><div></div></div></blockquote><div>Also as the deduction for normal fun=
ction is adopted to standard, you should consider if the declartion:<br><br=
>auto f(auto a, auto b);<br><br>Would be interpreted as:<br>template&lt;typ=
ename R, typename A, typename B&gt;<br>R f(A a, B b); //auto in return type=
 represents just another template argument.<br><br>Or:<br></div><div>templa=
te&lt;typename A, typename B&gt;<br>auto f(A a, B b); //auto is used for en=
abling deduction for return type.<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div><div>On Thursday, November 8, 2012 3:48:32 PM UTC-6, <a>t=
oma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>=
W dniu czwartek, 8 listopada 2012 06:08:18 UTC+1 u=BFytkownik <a>michael...=
@gmail.com</a> napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Templates =
can sometimes be quite verbose...<div><br></div><div><font face=3D"courier =
new, monospace">template &lt;typename Fn, typename T1, typename T2, typenam=
e T3&gt;</font></div><div><font face=3D"courier new, monospace">auto revers=
e_caller (Fn &amp;&amp; fn, T1 &amp;&amp; t1, T2 &amp;&amp; t2, T3 &amp;&am=
p; t3) -&gt; decltype(fn(t3, t2, t1)</font></div><div><font face=3D"courier=
 new, monospace">{</font></div><div><font face=3D"courier new, monospace">&=
nbsp; &nbsp; return fn(t3, t2, t1);</font></div><div><font face=3D"courier =
new, monospace">}</font></div><div><br></div><div>There is a lot of type in=
formation that is never used beyond declaring the function parameters. &nbs=
p;It would be much nicer if we could write this instead</div><div><br></div=
><div><font face=3D"courier new, monospace">template</font></div><div><font=
 face=3D"courier new, monospace">auto reverse_caller (auto &amp;&amp; fn, a=
uto &amp;&amp; t1, auto &amp;&amp; t2, auto &amp;&amp; t3) -&gt; decltype(f=
n(t3, t2, t1)</font></div><div><font face=3D"courier new, monospace">{</fon=
t></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; return fn(=
t3, t2, t1);</font></div><div><font face=3D"courier new, monospace">}</font=
></div></blockquote><div>This syntax dosen't work well if somone want mix t=
he template parameters with named type and deducted type. Example:<br>templ=
ate&lt;typename R&gt;<br>auto fn(auto &amp;a, R&amp; d) { return a+d; }<br>=
And for my opinion will conflict with explicit function template specjaliza=
tion. Maybe the syntax:<br>template&lt;...&gt; /* some unamed parametrs */<=
br>auto fn(auto &amp;a, auto&amp; b) { return a + b; }<br><br>And for the s=
econd example<br>template&lt;typename R, ...&gt;<br>auto fn(auto &amp;a, R&=
amp; d) { return a+d;  }<div><font face=3D"courier new, monospace"></font><=
/div>&nbsp;<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>This woul=
d be simplified even more if/when the normal-function return type deduction=
 makes it into the language. &nbsp;It wouldn't allow for specialization or =
for type defaults, but it would still be a useful syntax for many usages of=
 templates. &nbsp;We could also consider removing the template keyword here=
, but I feel that might be too asking too much from implementers as they wo=
uld have to consider every function declaration as a possible template unti=
l they discovered that there were no type-deduced parameters in the paramet=
er list.</div><div><br></div><div>Furthermore, we could also a similar tech=
nique for deducing template value parameters by throwing the constexpr keyw=
ord in there (unless this is already possible???)</div><div><br></div><div>=
<font face=3D"courier new, monospace">template &lt;int Base&gt;</font></div=
><div><font face=3D"courier new, monospace">int calculate (int val)</font><=
/div><div><font face=3D"courier new, monospace">{ return someOperation(Base=
, val); }</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><font face=3D"courier new, monospace">calculate&lt;10&gt;(5); /=
/ Usage... how strange.</font></div><div><br></div><div>versus</div><div><b=
r></div><div><font face=3D"courier new, monospace">template</font></div><di=
v><font face=3D"courier new, monospace">int calculate (constexpr int base, =
int val)</font></div><div><font face=3D"courier new, monospace">{ return so=
meOperation(base, val); }</font></div><div><font face=3D"courier new, monos=
pace"><br></font></div><div><font face=3D"courier new, monospace">calculate=
(10, 5); // This looks normal!</font></div><div><br></div><div>Note that th=
e latter could possibly be implemented as a constexpr-function but that may=
 not be possible, depending on the definition of someOperation and might al=
low &nbsp;some runtime computation that wasn't intended. &nbsp;It becomes e=
ven stronger when you combine the two approaches</div><div><br></div><div><=
div><font face=3D"courier new, monospace">template &lt;typename T, T Value&=
gt;</font></div><div><font face=3D"courier new, monospace">T incr () { retu=
rn Value+1; }</font></div></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><font face=3D"courier new, monospace">incr&lt;int, 5&=
gt;(); // Again, hard to parse for humans</font></div><div><br></div><div>v=
ersus</div><div><br></div><div><font face=3D"courier new, monospace">templa=
te</font></div><div><font face=3D"courier new, monospace">auto incr (conste=
xpr auto v) -&gt; decltype(v)</font></div><div><font face=3D"courier new, m=
onospace">{ return v+1; }</font></div><div><font face=3D"courier new, monos=
pace"><br></font></div><div><font face=3D"courier new, monospace">incr(5); =
// Looks like a normal function call!</font></div><div><br></div><div>So, I=
'm certain that there are dozens of horrible things that I have not conside=
red yet, but if this shows promise, I would love to turn this into a propos=
al. &nbsp;Please, show no mercy... ;-)</div></blockquote></blockquote></div=
></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_626_29412283.1352713890857--

.

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



On Monday, November 12, 2012 1:51:30 AM UTC-8, toma...@gmail.com wrote:
>
> W dniu poniedzia=C5=82ek, 12 listopada 2012 05:57:26 UTC+1 u=C5=BCytkowni=
k=20
> michael...@gmail.com napisa=C5=82:
>>
>> I could see some issues if the signatures of the specializations were=20
>> different, but I'm not familiar enough with the rules to say what those=
=20
>> issues would be.
>>
>> Thanks for the feedback!  Unless anyone is willing to pitch in and=20
>> champion this, it will take me a while to get it all down pat anyhow.
>>
>> Also as the deduction for normal function is adopted to standard, you=20
> should consider if the declartion:
>
> auto f(auto a, auto b);
>
> Would be interpreted as:
> template<typename R, typename A, typename B>
> R f(A a, B b); //auto in return type represents just another template=20
> argument.
>
>
This would be really great if this were added to the standard.  And it=20
would work nicely with the generic lambdas proposed by Dave Abrahams since=
=20
the committee is insisting on auto for the typename there (according to=20
Dave's post above).

Does anyone know if an official proposal has been made to allow 'auto' as a=
=20
shorthand way for expressing template parameters?

Thanks,
Ben

--=20




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

<br><br>On Monday, November 12, 2012 1:51:30 AM UTC-8, toma...@gmail.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">W dniu poniedzia=C5=82ek, =
12 listopada 2012 05:57:26 UTC+1 u=C5=BCytkownik <a>michael...@gmail.com</a=
> napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div></div=
><div>I could see some issues if the signatures of the specializations were=
 different, but I'm not familiar enough with the rules to say what those is=
sues would be.</div><div><br></div>Thanks for the feedback! &nbsp;Unless an=
yone is willing to pitch in and champion this, it will take me a while to g=
et it all down pat anyhow.</div><div><br></div><div></div></div></blockquot=
e><div>Also as the deduction for normal function is adopted to standard, yo=
u should consider if the declartion:<br><br>auto f(auto a, auto b);<br><br>=
Would be interpreted as:<br>template&lt;typename R, typename A, typename B&=
gt;<br>R f(A a, B b); //auto in return type represents just another templat=
e argument.<br><br></div></blockquote><div><br>This would be really great i=
f this were added to the standard.&nbsp; And it would work nicely with the =
generic lambdas proposed by Dave Abrahams since the committee is insisting =
on auto for the typename there (according to Dave's post above).<br><br>Doe=
s anyone know if an official proposal has been made to allow 'auto' as a sh=
orthand way for expressing template parameters?<br><br>Thanks,<br>Ben</div>=
<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_464_5150678.1352870878609--

.