Topic: [c++std-core-27199] [std-proposals] Re:
Author: "'Geoffrey Romer' via ISO C++ Standard - Discussion" <std-discussion@isocpp.org>
Date: Thu, 5 Mar 2015 10:10:44 -0800
Raw View
--001a11c1092e86533805108e7c3e
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 5, 2015 at 9:25 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 5 March 2015 at 11:11, 'Geoffrey Romer' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>
>>
>> This doesn't convey any useful information:
>>>
>>> template<typename T>
>>> void frob(T);
>>>
>>
>> I don't agree; it tells me that frob is a generic operation that works
>> with roughly any type T.
>>
>
> But what does that mean? Sure, I can copy/move it (since it was passed by
> value), but any other constraints will be dictated by the body of frob.
>
My point is that the use of a generic, meaningless parameter name like "T"
tacitly documents the fact that frob isn't going to dictate many additional
constraints, beyond perhaps highly generic ones like being able to compare
for equality.
>
>
>>
>>
>>> so in terms of describing the interface it's no different when written
>>> like this:
>>>
>>> void frob(auto);
>>>
>>
>> This is different because now I don't know anything about the
>> requirements or semantics of the parameter type.
>>
>
> I'm just not seeing how that is any different (other than the incredibly
> minor of having to call decltype on its parameter to get its type).
>
> Do you have an example function body that works with frob(T) but doesn't
> work with frob(auto) (or vice versa) for a specific concrete type? I'm
> really trying to understand the difference you see between these two forms.
>
I'm not aware of any code that will work with one form but not the other.
My point is simply that "auto" conveys less information to me as a human
reader than a named template parameter would.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
--001a11c1092e86533805108e7c3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Mar 5, 2015 at 9:25 AM, Nevin Liber <span dir=3D"ltr"><<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>></span> wrote:<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"><=
span class=3D"">On 5 March 2015 at 11:11, 'Geoffrey Romer' via ISO =
C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std=
-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></=
span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><span class=3D""><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 cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote"><span><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">This doesn't convey any useful information:<br>
<br>
template<typename T><br>
=C2=A0 void frob(T);<br></blockquote><div><br></div></span><div>I don't=
agree; it tells me that frob is a generic operation that works with roughl=
y any type T.</div></div></div></div></blockquote><div><br></div></span><di=
v>But what does that mean?=C2=A0 Sure, I can copy/move it (since it was pas=
sed by value), but any other constraints will be dictated by the body of fr=
ob.</div></div></div></div></blockquote><div><br></div><div>My point is tha=
t the use of a generic, meaningless parameter name like "T" tacit=
ly documents the fact that frob isn't going to dictate many additional =
constraints, beyond perhaps highly generic ones like being able to compare =
for equality.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><span><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">so in terms of describing the interface it'=
;s no different when written<br>
like this:<br>
<br>
void frob(auto);<br></blockquote><div><br></div></span><div>This is differe=
nt because now I don't know anything about the requirements or semantic=
s of the parameter type.</div></div></div></div></blockquote><div><br></div=
></span><div>I'm just not seeing how that is any different (other than =
the incredibly minor of having to call decltype on its parameter to get its=
type).</div><div><br></div><div>Do you have an example function body that =
works with frob(T) but doesn't work with frob(auto) (or vice versa) for=
a specific concrete type?=C2=A0 I'm really trying to understand the di=
fference you see between these two forms.</div></div></div></div></blockquo=
te><div><br></div><div>I'm not aware of any code that will work with on=
e form but not the other. My point is simply that "auto" conveys =
less information to me as a human reader than a named template parameter wo=
uld.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><span class=3D"HOEnZb"><font color=3D"#888888">-=
- <br><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a></div>
</font></span></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 - Discussion" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-discussion+unsubscribe@isocpp.org">std-discus=
sion+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-discussion@isocp=
p.org">std-discussion@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-discussion/">http://groups.google.com/a/isocpp.org/group/std-discussion=
/</a>.<br />
--001a11c1092e86533805108e7c3e--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Thu, 5 Mar 2015 15:28:09 -0500
Raw View
On 03/05/2015 01:10 PM, 'Geoffrey Romer' via ISO C++ Standard - Future
> I'm not aware of any code that will work with one form but not the
> other. My point is simply that "auto" conveys less information to me as
> a human reader than a named template parameter would.
I've felt concerns about this as well, specifically with respect to
behavioral differences observable in template functions vs non-template
functions.
We all know that there is one object with static storage duration
defined by this function:
void f(int i) {
static int invoke_count;
++invoke_count;
}
And we all know that there are potentially many objects with static
storage duration defined by this template function, one for each
instantiation:
template<typename T>
void f(int i) {
static int invoke_count;
++invoke_count;
}
But, it is less apparent how many objects with static storage duration
are defined by this function:
void f(auto t) {
static int invoke_count;
++invoke_count;
}
I don't know that this is a significant concern. But it is enough to
give me pause. I've personally never minded the template boilerplate,
but I guess I'm weird that way.
Tom.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Thu, 5 Mar 2015 15:43:15 -0800 (PST)
Raw View
------=_Part_88_1686668953.1425598995623
Content-Type: multipart/alternative;
boundary="----=_Part_89_1060952671.1425598995623"
------=_Part_89_1060952671.1425598995623
Content-Type: text/plain; charset=UTF-8
On Thursday, March 5, 2015 at 2:09:56 PM UTC-5, Ville Voutilainen wrote:
>
>
> void frob(auto t)
> {
> // if I want to use 'T' here, I need to do a decltype(t) to get at it
> }
>
You may need remove pointer, ref, and/or cv qualifiers if you use auto*,
auto&& (perfect forwarding), const auto&, etc.. using type_traits. If the
signature changes, you'll have to remember to fix the traits you used.
If your implementation needs to express type T, it might be better to use
the old template syntax.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
------=_Part_89_1060952671.1425598995623
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, March 5, 2015 at 2:09:56 PM UTC-5, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>void=
frob(auto t)
<br>{
<br> // if I want to use 'T' here, I need to do a decltype(t) =
to get at it
<br>}
<br></blockquote><div><br></div><div>You may need remove pointer, ref, and/=
or cv qualifiers if you use auto*, auto&& (perfect forwarding), con=
st auto&, etc.. using type_traits. If the signature changes, you'll hav=
e to remember to fix the traits you used. </div><div><br></div><div>If=
your implementation needs to express type T, it might be better to use the=
old template syntax.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Discussion" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-discussion+unsubscribe@isocpp.org">std-discus=
sion+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-discussion@isocp=
p.org">std-discussion@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-discussion/">http://groups.google.com/a/isocpp.org/group/std-discussion=
/</a>.<br />
------=_Part_89_1060952671.1425598995623--
------=_Part_88_1686668953.1425598995623--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 6 Mar 2015 01:52:39 +0200
Raw View
On 6 March 2015 at 01:43, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>> void frob(auto t)
>> {
>> // if I want to use 'T' here, I need to do a decltype(t) to get at it
>> }
> You may need remove pointer, ref, and/or cv qualifiers if you use auto*,
> auto&& (perfect forwarding), const auto&, etc.. using type_traits. If the
> signature changes, you'll have to remember to fix the traits you used.
Yes. Not that the "signature changes" is all that much different from an
old-skool template.
> If your implementation needs to express type T, it might be better to use
> the old template syntax.
Perhaps so. That may be a fairly big "if".
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
.
Author: Scott Prager <splinterofchaos@gmail.com>
Date: Thu, 5 Mar 2015 17:22:10 -0800 (PST)
Raw View
------=_Part_107_606478886.1425604930611
Content-Type: multipart/alternative;
boundary="----=_Part_108_1133248340.1425604930611"
------=_Part_108_1133248340.1425604930611
Content-Type: text/plain; charset=UTF-8
I can see where a lot of discomfort might come, here...
*(1) *Just plain auto seems imprecise and it makes template functions look
like
non-template functions.
*(2) *Named template parameters seem to provide comparatively more
information.
For *(1)*, this seems like a special case. When you consider inlining,
changing
functions that take reference parameters of basic types to pass by value,
and
other such optimizations our compilers perform, functions have never really
been the concrete entities we like to think of them as. I don't see a need
to
distinguish between template and non-template functions from a user
point-of-view, except when using *extern "C"*.
*(2)*: As mentioned, one can always fall back on normal template syntax, but
also, I don't know about anyone else, but I tend to name my types verbosely,
and my variables tersely. So I'll write...
template<class Sequence, class UnaryFunction>
void for_each(Sequence& seq, UnaryFunction f) { for(auto&& x : seq) f(x); }
....but with auto as the parameter type, I would reverse this trend:
void for_each(auto& sequence, auto unary_op) { for(auto&& x : sequence)
unary_op(x); }
....and I think that reads better.
Another reason I think we should embrace this: It brings template code
within
reach of absolute beginners, both to C++ and programming in general. Trying
to
teach an initiate what this means...
template<typename Function, typename Value>
auto f(Function fn, Value v) { return fn(v); }
requires teaching the meaning on "*typename*" (because the user may not have
needed typedefs or type aliases at this point), *template<...>*, how "
*Function*"
and "*Value*" do not denote real types, etc., etc.. But explaining this...
auto f(auto fn, auto val) { return fn(val); }
....well, they probably already are familiar with *auto*, using *auto* as a
parameter is intuitive, and those familiar with dynamic languages will feel
right at home, while benefiting from static typing.
On Thursday, March 5, 2015 at 6:52:40 PM UTC-5, Ville Voutilainen wrote:
>
> On 6 March 2015 at 01:43, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
> >> void frob(auto t)
> >> {
> >> // if I want to use 'T' here, I need to do a decltype(t) to get at
> it
> >> }
> > You may need remove pointer, ref, and/or cv qualifiers if you use auto*,
> > auto&& (perfect forwarding), const auto&, etc.. using type_traits. If
> the
> > signature changes, you'll have to remember to fix the traits you used.
>
> Yes. Not that the "signature changes" is all that much different from an
> old-skool template.
>
> > If your implementation needs to express type T, it might be better to
> use
> > the old template syntax.
>
> Perhaps so. That may be a fairly big "if".
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
------=_Part_108_1133248340.1425604930611
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I can see where a lot of discomfort might come, here.=
... </div><div><br></div><div><b>(1) </b>Just plain auto seems imprecis=
e and it makes template functions look like</div><div>non-template function=
s.</div><div><br></div><div><b>(2) </b>Named template parameters seem to pr=
ovide comparatively more information.</div><div><br></div><div>For <b>(1)</=
b>, this seems like a special case. When you consider inlining, changing</d=
iv><div>functions that take reference parameters of basic types to pass by =
value, and</div><div>other such optimizations our compilers perform, functi=
ons have never really</div><div>been the concrete entities we like to think=
of them as. I don't see a need to</div><div>distinguish between template a=
nd non-template functions from a user</div><div>point-of-view, except when =
using <i>extern "C"</i>.</div><div><br></div><div><b>(2)</b>: As mentioned,=
one can always fall back on normal template syntax, but</div><div>also, I =
don't know about anyone else, but I tend to name my types verbosely,</div><=
div>and my variables tersely. So I'll write...</div><div><br></div><div cla=
ss=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><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: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Seq=
uence</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: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">UnaryFunction</span><span style=3D"co=
lor: #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">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> for_each</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Sequence</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> seq</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">UnaryFunction</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: #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"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> seq</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span></div></code></div><div><br></div><div><br></div><div>...but with au=
to as the parameter type, I would reverse this trend:</div><div><br></div><=
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 clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> for_each</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> sequence</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" 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"> unary_op</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 style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> sequence</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> unary_op</span><span style=3D"=
color: #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;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span></div></code></div><br></div><div>...and I think that reads=
better.</div><div><br></div><div>Another reason I think we should embrace =
this: It brings template code within</div><div>reach of absolute beginners,=
both to C++ and programming in general. Trying to</div><div>teach an initi=
ate what this means...</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"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"><</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"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #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"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Value</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> fn</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">Value</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> fn</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span></div></code></div><div><br></div><div>requires teaching t=
he meaning on "<i>typename</i>" (because the user may not have</div><div>ne=
eded typedefs or type aliases at this point), <i>template<...></i>, h=
ow "<i>Function</i>"</div><div>and "<i>Value</i>" do not denote real types,=
etc., etc.. But explaining this...</div><div><br></div><div><div class=3D"=
prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn</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: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> val</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">val</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span></div></code></div></div><div><br></div><div>...=
well, they probably already are familiar with <i>auto</i>, using <i>auto</i=
> as a</div><div>parameter is intuitive, and those familiar with dynamic la=
nguages will feel</div><div>right at home, while benefiting from static typ=
ing.<br></div><br>On Thursday, March 5, 2015 at 6:52:40 PM UTC-5, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6 March 2015=
at 01:43, Matthew Fioravante <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"DORbBlHhyyoJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">fmatth...@gmail.com</a>> wrote:
<br>>> void frob(auto t)
<br>>> {
<br>>> // if I want to use 'T' here, I need to do a dec=
ltype(t) to get at it
<br>>> }
<br>> You may need remove pointer, ref, and/or cv qualifiers if you use =
auto*,
<br>> auto&& (perfect forwarding), const auto&, etc.. using =
type_traits. If the
<br>> signature changes, you'll have to remember to fix the traits you u=
sed.
<br>
<br>Yes. Not that the "signature changes" is all that much different from a=
n
<br>old-skool template.
<br>
<br>> If your implementation needs to express type T, it might be better=
to use
<br>> the old template syntax.
<br>
<br>Perhaps so. That may be a fairly big "if".
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Discussion" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-discussion+unsubscribe@isocpp.org">std-discus=
sion+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-discussion@isocp=
p.org">std-discussion@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-discussion/">http://groups.google.com/a/isocpp.org/group/std-discussion=
/</a>.<br />
------=_Part_108_1133248340.1425604930611--
------=_Part_107_606478886.1425604930611--
.