Topic: [c++std-core-27208] An implementation of
Author: "'Richard Smith' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 5 Mar 2015 17:01:24 -0800
Raw View
--485b397dd6353730a60510943941
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 5 March 2015 at 16:24, Herb Sutter <hsutter@microsoft.com> wrote:
> To paraphrase Stroustrup, it=E2=80=99s not about functional programming =
and
> object-oriented programming and generic programming=E2=80=A6 =E2=80=9Cit=
=E2=80=99s all *just
> programming*.=E2=80=9D
>
>
>
> > Templates are a fundamentally different kind of construct
>
>
>
> Why? Every full specialization of a function template is just a function.
>
>
>
> > My issue is with, well, any syntax that declares a template without
> having to type either the word "template" or the use of "<>" brackets.
>
>
>
> That ship has sailed:
>
>
>
> auto plus =3D [](auto x, auto y) { return x+y; }
>
>
>
> which even already decays to an ordinary pointer to function, etc.
>
>
>
> Clarifying Q: Are we mainly arguing about whether to require the three
> characters =3D, [, and ] ?
>
>
>
> Not only has the ship sailed, but I for one like the direction it=E2=80=
=99s
> sailing. I see no reason why functions should be forced to spell =E2=80=
=9Ctemplate=E2=80=9D
> and =E2=80=9C<>=E2=80=9D. What value does it add? It=E2=80=99s =E2=80=9Cj=
ust programming.=E2=80=9D In fact, if we
> didn=E2=80=99t have backward compatibility issues with unnamed parameters=
and such,
> I=E2=80=99d personally probably be fine with just =E2=80=9Cauto plus(x,y)=
{x+y}=E2=80=9D as an
> equivalent function definition. That still doesn=E2=80=99t lose any infor=
mation.
>
>
>
> Gratuitous syntax is often unnecessary and usually harmful. Saying
>
>
>
> template<class T, class U>
>
> auto(T x, U y) -> decltype(x+y) { return x+y; }
>
>
>
> does not appear to me to contain any more information than
>
>
>
> auto plus(auto x, auto y) { return x+y; }
>
>
>
> does it?
>
To me, yes, it does. It says:
* I deliberately want to allow the parameters to have different types
* I deliberately want to allow the return type to differ from those types
* I want a substitution failure if x + y is not valid (your rewrite is
possibly incorrect due to this)
* I want to "perfectly return" x + y rather than always returning by value
(your rewrite is possibly incorrect due to this)
* It's OK for this apparent function definition to be in a header file
despite not including the 'inline' keyword
* It's *not* OK to move this definition out of the header file.
* And the big one: it says "this is a template". No need to go scanning
the declaration for "auto" (or for concept names, not that you can identify
them by sight). It's right there at the start.
It's somewhat less clear to me how this loss of readability balances
against the possibility of improved readability from a shorter declaration.
Requiring the verbose syntax is gratuitous, if the verbose syntax does not
> add information, does not serve to disambiguate anything, and does not
> highlight a dangerous operation or anything else I can see that deserves =
to
> have attention called to it.
>
>
>
> There=E2=80=99s a disturbing (to me and at least some others) trend in C+=
+ these
> days: People seem to be very prone to wanting =E2=80=9Cmore syntax=E2=80=
=9D lately. It=E2=80=99s
> rather Vasa-like, if only lexically. Let me channel certain influential
> committee members and say: =E2=80=98People these days are always asking f=
or more
> syntax! There=E2=80=99s no proposal they=E2=80=99ve seen that they couldn=
=E2=80=99t make uglier
> with more syntax!=E2=80=99
>
>
>
> Important note: The point here is NOT terseness for terseness=E2=80=99 sa=
ke. I am
> not arguing that terser is somehow better, that terseness is virtuous in
> itself. Too many people glorify languages because they=E2=80=99re terser;=
fewer
> characters alone doesn=E2=80=99t make code clearer. Rather, my point is t=
o avoid
> gratuitous verbosity. At the other end of the pendulum, too many people
> glorify verbose syntax because they think _that_ is somehow inherently
> clearer; usually it isn=E2=80=99t. So I am arguing that neither is verbos=
ity
> virtuous in itself.
>
Right; we need to find a balance where the syntax we have is neither
unnecessarily terse (to the point of causing readability and maintenance
problems) nor unnecessarily verbose. It is up to the people proposing the
change to demonstrate that this requirement is met, and the reactions on
this thread seem to suggest that we are, so far, lacking a good argument
that the proposed syntax meets the Goldilocks criterion.
Herb
>
>
>
>
>
> *From:* Nicol Bolas [mailto:jmckesson@gmail.com]
> *Sent:* Thursday, March 5, 2015 3:19 PM
> *To:* std-discussion@isocpp.org
> *Cc:* std-proposals@isocpp.org; c++std-core@accu.org; faisalv@gmail.com
> *Subject:* [c++std-core-27204] Re: An implementation of enhanced auto
> deduction and abbreviated template syntax using Clang
>
>
>
> I... just... ugh.
>
> I'm fine with type deduction patterns like std::vector<auto> =3D ...; Tha=
t's
> just a generalization of type deduction in static contexts.
>
> My issue is with, well, any syntax that declares a template without havin=
g
> to type either the word "template" or the use of "<>" brackets. Templates
> are a fundamentally different kind of construct, and we have specific
> syntax for doing so. By removing that syntax, it becomes way too easy to
> not notice that you've declared a template.
>
> The last thing we should want is for people to accidentally make somethin=
g
> a template.
>
> I accept this with lambdas, because the main point of lambdas is that
> they're a short-cut. Furthermore, they have a syntax that's fundamentally
> different from regular functions. But for a regular function? No.
>
> Basically, if I see this:
>
> X func_name(...);
>
> I expect that &func_name ought to return a pointer. For it to do somethin=
g
> else, like being a compiler error, would be surprising.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--485b397dd6353730a60510943941
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 5=
March 2015 at 16:24, Herb Sutter <span dir=3D"ltr"><<a href=3D"mailto:h=
sutter@microsoft.com" target=3D"_blank">hsutter@microsoft.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">To paraphrase Stroustrup, it=E2=80=99=
s not about functional programming and object-oriented programming and gene=
ric programming=E2=80=A6 =E2=80=9Cit=E2=80=99s all
<i>just programming</i>.=E2=80=9D<u></u><u></u></span></p><span class=3D"">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">>
</span>Templates are a fundamentally different kind of construct<span style=
=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f49=
7d"><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
</span><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri",sans-serif;color:#1f497d">Why? Every full specialization=
of a function template is just a function.<u></u><u></u></span></p><span c=
lass=3D"">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">>
</span>My issue is with, well, any syntax that declares a template without =
having to type either the word "template" or the use of "<=
;>" brackets.<span style=3D"font-size:11.0pt;font-family:"Cali=
bri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
</span><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri",sans-serif;color:#1f497d">That ship has sailed:<u></u><u=
></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto plus =3D [](aut=
o x, auto y) { return x+y; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">which even already decays to an ordin=
ary pointer to function, etc.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Clarifying Q: Are we mainly arguing a=
bout whether to require the three characters =3D, [, and ] ?<u></u><u></u><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Not only has the ship sailed, but I f=
or one like the direction it=E2=80=99s sailing. I see no reason why functio=
ns should be forced to spell =E2=80=9Ctemplate=E2=80=9D and =E2=80=9C<&g=
t;=E2=80=9D. What
value does it add? It=E2=80=99s =E2=80=9Cjust programming.=E2=80=9D In fac=
t, if we didn=E2=80=99t have backward compatibility issues with unnamed par=
ameters and such, I=E2=80=99d personally probably be fine with just =E2=80=
=9Cauto plus(x,y){x+y}=E2=80=9D as an equivalent function definition. That =
still doesn=E2=80=99t
lose any information.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Gratuitous syntax is often unnecessar=
y and usually harmful. Saying<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template<class T,=
class U><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto(T x, U y) ->=
decltype(x+y) { return x+y; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">does not appear to me to contain any =
more information than<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto plus(auto x, au=
to y) { return x+y; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">does it?</span></p></div></div></bloc=
kquote><div><br></div><div>To me, yes, it does. It says:</div><div><br></di=
v><div>=C2=A0* I deliberately want to allow the parameters to have differen=
t types</div><div>=C2=A0* I deliberately want to allow the return type to d=
iffer from those types</div><div>=C2=A0* I want a substitution failure if x=
+ y is not valid (your rewrite is possibly incorrect due to this)</div><di=
v>=C2=A0* I want to "perfectly return" x + y rather than always r=
eturning by value (your rewrite is possibly incorrect due to this)</div><di=
v>=C2=A0* It's OK for this apparent function definition to be in a head=
er file despite not including the 'inline' keyword</div><div>=C2=A0=
* It's *not* OK to move this definition out of the header file.</div><d=
iv>=C2=A0* And the big one: it says "this is a template". No need=
to go scanning the declaration for "auto" (or for concept names,=
not that you can identify them by sight). It's right there at the star=
t.</div><div><br></div><div>It's somewhat less clear to me how this los=
s of readability balances against the possibility of improved readability f=
rom a shorter declaration.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"><div><p class=3D"=
MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri",=
sans-serif;color:#1f497d">Requiring the verbose syntax is gratuitous, if th=
e verbose syntax does not add information, does not serve to disambiguate a=
nything, and does not highlight
a dangerous operation or anything else I can see that deserves to have att=
ention called to it.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">There=E2=80=99s a disturbing (to me a=
nd at least some others) trend in C++ these days: People seem to be very pr=
one to wanting =E2=80=9Cmore syntax=E2=80=9D lately. It=E2=80=99s rather Va=
sa-like,
if only lexically. Let me channel certain influential committee members an=
d say: =E2=80=98People these days are always asking for more syntax! There=
=E2=80=99s no proposal they=E2=80=99ve seen that they couldn=E2=80=99t make=
uglier with more syntax!=E2=80=99<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Important note: The point here is NOT=
terseness for terseness=E2=80=99 sake. I am not arguing that terser is som=
ehow better, that terseness is virtuous in itself. Too
many people glorify languages because they=E2=80=99re terser; fewer charac=
ters alone doesn=E2=80=99t make code clearer. Rather, my point is to avoid =
gratuitous verbosity. At the other end of the pendulum, too many people glo=
rify verbose syntax because they think _that_ is
somehow inherently clearer; usually it isn=E2=80=99t. So I am arguing that=
neither is verbosity virtuous in itself.</span></p></div></div></blockquot=
e><div><br></div><div>Right; we need to find a balance where the syntax we =
have is neither unnecessarily terse (to the point of causing readability an=
d maintenance problems) nor unnecessarily verbose. It is up to the people p=
roposing the change to demonstrate that this requirement is met, and the re=
actions on this thread seem to suggest that we are, so far, lacking a good =
argument that the proposed syntax meets the Goldilocks criterion.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"#0563=
C1" vlink=3D"#954F72"><div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Herb<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"=
;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:"Calibri",sans-serif"> Nicol Bolas [mailto:<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, March 5, 2015 3:19 PM<br>
<b>To:</b> <a href=3D"mailto:std-discussion@isocpp.org" target=3D"_blank">s=
td-discussion@isocpp.org</a><br>
<b>Cc:</b> <a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">st=
d-proposals@isocpp.org</a>; <a href=3D"mailto:c%2B%2Bstd-core@accu.org" tar=
get=3D"_blank">c++std-core@accu.org</a>; <a href=3D"mailto:faisalv@gmail.co=
m" target=3D"_blank">faisalv@gmail.com</a><br>
<b>Subject:</b> [c++std-core-27204] Re: An implementation of enhanced auto =
deduction and abbreviated template syntax using Clang<u></u><u></u></span><=
/p>
</div>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal">I... just... ugh.<br>
<br>
I'm fine with type deduction patterns like std::vector<auto> =3D =
....; That's just a generalization of type deduction in static contexts.=
<br>
<br>
My issue is with, well, any syntax that declares a template without having =
to type either the word "template" or the use of "<>&q=
uot; brackets. Templates are a fundamentally different kind of construct, a=
nd we have specific syntax for doing so. By removing that
syntax, it becomes way too easy to not notice that you've declared a t=
emplate.<br>
<br>
The last thing we should want is for people to accidentally make something =
a template.<br>
<br>
I accept this with lambdas, because the main point of lambdas is that they&=
#39;re a short-cut. Furthermore, they have a syntax that's fundamentall=
y different from regular functions. But for a regular function? No.<br>
<br>
Basically, if I see this:<br>
<br>
X func_name(...);<br>
<br>
I expect that &func_name ought to return a pointer. For it to do someth=
ing else, like being a compiler error, would be surprising.<u></u><u></u></=
p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--485b397dd6353730a60510943941--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 5 Mar 2015 17:08:16 -0800
Raw View
--001a1132e6c8cb79780510945105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 5 Mar 2015 5:01 pm, "'Richard Smith' via ISO C++ Standard - Discussion" =
<
std-discussion@isocpp.org> wrote:
>
> On 5 March 2015 at 16:24, Herb Sutter <hsutter@microsoft.com> wrote:
>>
>> To paraphrase Stroustrup, it=E2=80=99s not about functional programming =
and
object-oriented programming and generic programming=E2=80=A6 =E2=80=9Cit=E2=
=80=99s all just
programming.=E2=80=9D
>>
>>
>>
>> > Templates are a fundamentally different kind of construct
>>
>>
>>
>> Why? Every full specialization of a function template is just a function=
..
>>
>>
>>
>> > My issue is with, well, any syntax that declares a template without
having to type either the word "template" or the use of "<>" brackets.
>>
>>
>>
>> That ship has sailed:
>>
>>
>>
>> auto plus =3D [](auto x, auto y) { return x+y; }
>>
>>
>>
>> which even already decays to an ordinary pointer to function, etc.
>>
>>
>>
>> Clarifying Q: Are we mainly arguing about whether to require the three
characters =3D, [, and ] ?
>>
>>
>>
>> Not only has the ship sailed, but I for one like the direction it=E2=80=
=99s
sailing. I see no reason why functions should be forced to spell =E2=80=9Ct=
emplate=E2=80=9D
and =E2=80=9C<>=E2=80=9D. What value does it add? It=E2=80=99s =E2=80=9Cjus=
t programming.=E2=80=9D In fact, if we
didn=E2=80=99t have backward compatibility issues with unnamed parameters a=
nd such,
I=E2=80=99d personally probably be fine with just =E2=80=9Cauto plus(x,y){x=
+y}=E2=80=9D as an
equivalent function definition. That still doesn=E2=80=99t lose any informa=
tion.
>>
>>
>>
>> Gratuitous syntax is often unnecessary and usually harmful. Saying
>>
>>
>>
>> template<class T, class U>
>>
>> auto(T x, U y) -> decltype(x+y) { return x+y; }
>>
>>
>>
>> does not appear to me to contain any more information than
>>
>>
>>
>> auto plus(auto x, auto y) { return x+y; }
>>
>>
>>
>> does it?
>
>
> To me, yes, it does. It says:
>
> * I deliberately want to allow the parameters to have different types
> * I deliberately want to allow the return type to differ from those type=
s
> * I want a substitution failure if x + y is not valid (your rewrite is
possibly incorrect due to this)
> * I want to "perfectly return" x + y rather than always returning by
value (your rewrite is possibly incorrect due to this)
> * It's OK for this apparent function definition to be in a header file
despite not including the 'inline' keyword
> * It's *not* OK to move this definition out of the header file.
> * And the big one: it says "this is a template". No need to go scanning
the declaration for "auto" (or for concept names, not that you can identify
them by sight). It's right there at the start.
>
> It's somewhat less clear to me how this loss of readability balances
against the possibility of improved readability from a shorter declaration.
>
>> Requiring the verbose syntax is gratuitous, if the verbose syntax does
not add information, does not serve to disambiguate anything, and does not
highlight a dangerous operation or anything else I can see that deserves to
have attention called to it.
>>
>>
>>
>> There=E2=80=99s a disturbing (to me and at least some others) trend in C=
++ these
days: People seem to be very prone to wanting =E2=80=9Cmore syntax=E2=80=9D=
lately. It=E2=80=99s
rather Vasa-like, if only lexically. Let me channel certain influential
committee members and say: =E2=80=98People these days are always asking for=
more
syntax! There=E2=80=99s no proposal they=E2=80=99ve seen that they couldn=
=E2=80=99t make uglier
with more syntax!=E2=80=99
>>
>>
>>
>> Important note: The point here is NOT terseness for terseness=E2=80=99 s=
ake. I
am not arguing that terser is somehow better, that terseness is virtuous in
itself. Too many people glorify languages because they=E2=80=99re terser; f=
ewer
characters alone doesn=E2=80=99t make code clearer. Rather, my point is to =
avoid
gratuitous verbosity. At the other end of the pendulum, too many people
glorify verbose syntax because they think _that_ is somehow inherently
clearer; usually it isn=E2=80=99t. So I am arguing that neither is verbosit=
y
virtuous in itself.
>
>
> Right; we need to find a balance where the syntax we have is neither
unnecessarily terse (to the point of causing readability and maintenance
problems) nor unnecessarily verbose. It is up to the people proposing the
change to demonstrate that this requirement is met, and the reactions on
this thread seem to suggest that we are, so far, lacking a good argument
that the proposed syntax meets the Goldilocks criterion.
Incidentally, this is one thing I love about the concepts TS: it lets us
form a much stronger argument about the merits here based on actual user
experience.
>> Herb
>>
>>
>>
>>
>>
>> From: Nicol Bolas [mailto:jmckesson@gmail.com]
>> Sent: Thursday, March 5, 2015 3:19 PM
>> To: std-discussion@isocpp.org
>> Cc: std-proposals@isocpp.org; c++std-core@accu.org; faisalv@gmail.com
>> Subject: [c++std-core-27204] Re: An implementation of enhanced auto
deduction and abbreviated template syntax using Clang
>>
>>
>>
>> I... just... ugh.
>>
>> I'm fine with type deduction patterns like std::vector<auto> =3D ...;
That's just a generalization of type deduction in static contexts.
>>
>> My issue is with, well, any syntax that declares a template without
having to type either the word "template" or the use of "<>" brackets.
Templates are a fundamentally different kind of construct, and we have
specific syntax for doing so. By removing that syntax, it becomes way too
easy to not notice that you've declared a template.
>>
>> The last thing we should want is for people to accidentally make
something a template.
>>
>> I accept this with lambdas, because the main point of lambdas is that
they're a short-cut. Furthermore, they have a syntax that's fundamentally
different from regular functions. But for a regular function? No.
>>
>> Basically, if I see this:
>>
>> X func_name(...);
>>
>> I expect that &func_name ought to return a pointer. For it to do
something else, like being a compiler error, would be surprising.
>
>
> --
>
> ---
> 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/.
--=20
---=20
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 e=
mail 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-discuss=
ion/.
--001a1132e6c8cb79780510945105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On 5 Mar 2015 5:01 pm, "'Richard Smith' via ISO=
C++ Standard - Discussion" <<a href=3D"mailto:std-discussion@isocp=
p.org">std-discussion@isocpp.org</a>> wrote:<br>
><br>
> On 5 March 2015 at 16:24, Herb Sutter <<a href=3D"mailto:hsutter@mi=
crosoft.com">hsutter@microsoft.com</a>> wrote:<br>
>><br>
>> To paraphrase Stroustrup, it=E2=80=99s not about functional progra=
mming and object-oriented programming and generic programming=E2=80=A6 =E2=
=80=9Cit=E2=80=99s all just programming.=E2=80=9D<br>
>><br>
>> =C2=A0<br>
>><br>
>> > Templates are a fundamentally different kind of construct<br>
>><br>
>> =C2=A0<br>
>><br>
>> Why? Every full specialization of a function template is just a fu=
nction.<br>
>><br>
>> =C2=A0<br>
>><br>
>> > My issue is with, well, any syntax that declares a template w=
ithout having to type either the word "template" or the use of &q=
uot;<>" brackets.<br>
>><br>
>> =C2=A0<br>
>><br>
>> That ship has sailed:<br>
>><br>
>> =C2=A0<br>
>><br>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 auto plus =3D [](auto x, auto y) { return x+y; }<b=
r>
>><br>
>> =C2=A0<br>
>><br>
>> which even already decays to an ordinary pointer to function, etc.=
<br>
>><br>
>> =C2=A0<br>
>><br>
>> Clarifying Q: Are we mainly arguing about whether to require the t=
hree characters =3D, [, and ] ?<br>
>><br>
>> =C2=A0<br>
>><br>
>> Not only has the ship sailed, but I for one like the direction it=
=E2=80=99s sailing. I see no reason why functions should be forced to spell=
=E2=80=9Ctemplate=E2=80=9D and =E2=80=9C<>=E2=80=9D. What value does=
it add? It=E2=80=99s =E2=80=9Cjust programming.=E2=80=9D In fact, if we di=
dn=E2=80=99t have backward compatibility issues with unnamed parameters and=
such, I=E2=80=99d personally probably be fine with just =E2=80=9Cauto plus=
(x,y){x+y}=E2=80=9D as an equivalent function definition. That still doesn=
=E2=80=99t lose any information.<br>
>><br>
>> =C2=A0<br>
>><br>
>> Gratuitous syntax is often unnecessary and usually harmful. Saying=
<br>
>><br>
>> =C2=A0<br>
>><br>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 template<class T, class U><br>
>><br>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 auto(T x, U y) -> decltype(x+y) { return x+y; }=
<br>
>><br>
>> =C2=A0<br>
>><br>
>> does not appear to me to contain any more information than<br>
>><br>
>> =C2=A0<br>
>><br>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 auto plus(auto x, auto y) { return x+y; }<br>
>><br>
>> =C2=A0<br>
>><br>
>> does it?<br>
><br>
><br>
> To me, yes, it does. It says:<br>
><br>
> =C2=A0* I deliberately want to allow the parameters to have different =
types<br>
> =C2=A0* I deliberately want to allow the return type to differ from th=
ose types<br>
> =C2=A0* I want a substitution failure if x + y is not valid (your rewr=
ite is possibly incorrect due to this)<br>
> =C2=A0* I want to "perfectly return" x + y rather than alway=
s returning by value (your rewrite is possibly incorrect due to this)<br>
> =C2=A0* It's OK for this apparent function definition to be in a h=
eader file despite not including the 'inline' keyword<br>
> =C2=A0* It's *not* OK to move this definition out of the header fi=
le.<br>
> =C2=A0* And the big one: it says "this is a template". No ne=
ed to go scanning the declaration for "auto" (or for concept name=
s, not that you can identify them by sight). It's right there at the st=
art.<br>
><br>
> It's somewhat less clear to me how this loss of readability balanc=
es against the possibility of improved readability from a shorter declarati=
on.<br>
><br>
>> Requiring the verbose syntax is gratuitous, if the verbose syntax =
does not add information, does not serve to disambiguate anything, and does=
not highlight a dangerous operation or anything else I can see that deserv=
es to have attention called to it.<br>
>><br>
>> =C2=A0<br>
>><br>
>> There=E2=80=99s a disturbing (to me and at least some others) tren=
d in C++ these days: People seem to be very prone to wanting =E2=80=9Cmore =
syntax=E2=80=9D lately. It=E2=80=99s rather Vasa-like, if only lexically. L=
et me channel certain influential committee members and say: =E2=80=98Peopl=
e these days are always asking for more syntax! There=E2=80=99s no proposal=
they=E2=80=99ve seen that they couldn=E2=80=99t make uglier with more synt=
ax!=E2=80=99<br>
>><br>
>> =C2=A0<br>
>><br>
>> Important note: The point here is NOT terseness for terseness=E2=
=80=99 sake. I am not arguing that terser is somehow better, that terseness=
is virtuous in itself. Too many people glorify languages because they=E2=
=80=99re terser; fewer characters alone doesn=E2=80=99t make code clearer. =
Rather, my point is to avoid gratuitous verbosity. At the other end of the =
pendulum, too many people glorify verbose syntax because they think _that_ =
is somehow inherently clearer; usually it isn=E2=80=99t. So I am arguing th=
at neither is verbosity virtuous in itself.<br>
><br>
><br>
> Right; we need to find a balance where the syntax we have is neither u=
nnecessarily terse (to the point of causing readability and maintenance pro=
blems) nor unnecessarily verbose. It is up to the people proposing the chan=
ge to demonstrate that this requirement is met, and the reactions on this t=
hread seem to suggest that we are, so far, lacking a good argument that the=
proposed syntax meets the Goldilocks criterion.</p>
<p dir=3D"ltr">Incidentally, this is one thing I love about the concepts TS=
: it lets us form a much stronger argument about the merits here based on a=
ctual user experience.</p>
<p dir=3D"ltr">>> Herb<br>
>><br>
>> =C2=A0<br>
>><br>
>> =C2=A0<br>
>><br>
>> From: Nicol Bolas [mailto:<a href=3D"mailto:jmckesson@gmail.com">j=
mckesson@gmail.com</a>] <br>
>> Sent: Thursday, March 5, 2015 3:19 PM<br>
>> To: <a href=3D"mailto:std-discussion@isocpp.org">std-discussion@is=
ocpp.org</a><br>
>> Cc: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isoc=
pp.org</a>; <a href=3D"mailto:c%2B%2Bstd-core@accu.org">c++std-core@accu.or=
g</a>; <a href=3D"mailto:faisalv@gmail.com">faisalv@gmail.com</a><br>
>> Subject: [c++std-core-27204] Re: An implementation of enhanced aut=
o deduction and abbreviated template syntax using Clang<br>
>><br>
>> =C2=A0<br>
>><br>
>> I... just... ugh.<br>
>><br>
>> I'm fine with type deduction patterns like std::vector<auto=
> =3D ...; That's just a generalization of type deduction in static =
contexts.<br>
>><br>
>> My issue is with, well, any syntax that declares a template withou=
t having to type either the word "template" or the use of "&=
lt;>" brackets. Templates are a fundamentally different kind of con=
struct, and we have specific syntax for doing so. By removing that syntax, =
it becomes way too easy to not notice that you've declared a template.<=
br>
>><br>
>> The last thing we should want is for people to accidentally make s=
omething a template.<br>
>><br>
>> I accept this with lambdas, because the main point of lambdas is t=
hat they're a short-cut. Furthermore, they have a syntax that's fun=
damentally different from regular functions. But for a regular function? No=
..<br>
>><br>
>> Basically, if I see this:<br>
>><br>
>> X func_name(...);<br>
>><br>
>> I expect that &func_name ought to return a pointer. For it to =
do something else, like being a compiler error, would be surprising.<br>
><br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Discussion" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-discussion%2Bunsubscribe@isocpp.org">std=
-discussion+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-discussion@=
isocpp.org">std-discussion@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-discussion/">http://groups.google.com/a/isocpp.org/group/std-discu=
ssion/</a>.<br>
</p>
<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 />
--001a1132e6c8cb79780510945105--
.
Author: Scott Prager <splinterofchaos@gmail.com>
Date: Thu, 5 Mar 2015 17:30:55 -0800 (PST)
Raw View
------=_Part_92_927360727.1425605455125
Content-Type: multipart/alternative;
boundary="----=_Part_93_1862912410.1425605455125"
------=_Part_93_1862912410.1425605455125
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 5, 2015 at 8:01:26 PM UTC-5, Richard Smith wrote:
>
> On 5 March 2015 at 16:24, Herb Sutter <hsu...@microsoft.com <javascript:>=
>=20
> wrote:
>>
>> =20
> Gratuitous syntax is often unnecessary and usually harmful. Saying
>>
>> =20
>>
>> template<class T, class U>
>>
>> auto(T x, U y) -> decltype(x+y) { return x+y; }
>>
>> =20
>>
>> does not appear to me to contain any more information than
>>
>> =20
>>
>> auto plus(auto x, auto y) { return x+y; }
>>
>> =20
>>
>> does it?
>>
>
> To me, yes, it does. It says:
>
> * I deliberately want to allow the parameters to have different types
>
* I deliberately want to allow the return type to differ from those types
>
Does that mean that the version using auto *accidentally* allows the=20
arguments to have different types, and return a different type?
=20
> * I want a substitution failure if x + y is not valid (your rewrite is=
=20
> possibly incorrect due to this)
>
* I want to "perfectly return" x + y rather than always returning by value=
=20
> (your rewrite is possibly incorrect due to this)
>
* It's OK for this apparent function definition to be in a header file=20
> despite not including the 'inline' keyword
>
Does the use of *auto* as a parameter not also convey that? If it's treated=
=20
consistently like a template function, I'd think it should.
=20
> * It's *not* OK to move this definition out of the header file.
>
Use of *auto* as a return type implies that, since the definition must be=
=20
in the TU.
=20
> * And the big one: it says "this is a template". No need to go scanning=
=20
> the declaration for "auto" (or for concept names, not that you can identi=
fy=20
> them by sight). It's right there at the start.
>
> It's somewhat less clear to me how this loss of readability balances=20
> against the possibility of improved readability from a shorter declaratio=
n.
>
> Requiring the verbose syntax is gratuitous, if the verbose syntax does no=
t=20
>> add information, does not serve to disambiguate anything, and does not=
=20
>> highlight a dangerous operation or anything else I can see that deserves=
to=20
>> have attention called to it.
>>
>> =20
>>
>> There=E2=80=99s a disturbing (to me and at least some others) trend in C=
++ these=20
>> days: People seem to be very prone to wanting =E2=80=9Cmore syntax=E2=80=
=9D lately. It=E2=80=99s=20
>> rather Vasa-like, if only lexically. Let me channel certain influential=
=20
>> committee members and say: =E2=80=98People these days are always asking =
for more=20
>> syntax! There=E2=80=99s no proposal they=E2=80=99ve seen that they could=
n=E2=80=99t make uglier=20
>> with more syntax!=E2=80=99
>>
>> =20
>>
>> Important note: The point here is NOT terseness for terseness=E2=80=99 s=
ake. I am=20
>> not arguing that terser is somehow better, that terseness is virtuous in=
=20
>> itself. Too many people glorify languages because they=E2=80=99re terser=
; fewer=20
>> characters alone doesn=E2=80=99t make code clearer. Rather, my point is =
to avoid=20
>> gratuitous verbosity. At the other end of the pendulum, too many people=
=20
>> glorify verbose syntax because they think _that_ is somehow inherently=
=20
>> clearer; usually it isn=E2=80=99t. So I am arguing that neither is verbo=
sity=20
>> virtuous in itself.
>>
>
> Right; we need to find a balance where the syntax we have is neither=20
> unnecessarily terse (to the point of causing readability and maintenance=
=20
> problems) nor unnecessarily verbose. It is up to the people proposing the=
=20
> change to demonstrate that this requirement is met, and the reactions on=
=20
> this thread seem to suggest that we are, so far, lacking a good argument=
=20
> that the proposed syntax meets the Goldilocks criterion.
>
> Herb
>>
>> =20
>>
>> =20
>> =20
>> *From:* Nicol Bolas [mailto:jmck...@gmail.com <javascript:>]=20
>> *Sent:* Thursday, March 5, 2015 3:19 PM
>> *To:* std-dis...@isocpp.org <javascript:>
>> *Cc:* std-pr...@isocpp.org <javascript:>; c++st...@accu.org <javascript:=
>;=20
>> fai...@gmail.com <javascript:>
>> *Subject:* [c++std-core-27204] Re: An implementation of enhanced auto=20
>> deduction and abbreviated template syntax using Clang
>> =20
>> =20
>> =20
>> I... just... ugh.
>>
>> I'm fine with type deduction patterns like std::vector<auto> =3D ...;=20
>> That's just a generalization of type deduction in static contexts.
>>
>> My issue is with, well, any syntax that declares a template without=20
>> having to type either the word "template" or the use of "<>" brackets.=
=20
>> Templates are a fundamentally different kind of construct, and we have=
=20
>> specific syntax for doing so. By removing that syntax, it becomes way to=
o=20
>> easy to not notice that you've declared a template.
>>
>> The last thing we should want is for people to accidentally make=20
>> something a template.
>>
>> I accept this with lambdas, because the main point of lambdas is that=20
>> they're a short-cut. Furthermore, they have a syntax that's fundamentall=
y=20
>> different from regular functions. But for a regular function? No.
>>
>> Basically, if I see this:
>>
>> X func_name(...);
>>
>> I expect that &func_name ought to return a pointer. For it to do=20
>> something else, like being a compiler error, would be surprising.
>> =20
>
--=20
---=20
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 e=
mail 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-discuss=
ion/.
------=_Part_93_1862912410.1425605455125
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, March 5, 2015 at 8:01:26 PM UTC-5, Ri=
chard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On 5 March 2015 at 16:24, Herb Sutter =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"LWPz-Z9ZqEMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>hsu...@microsoft.com</a>></span> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:11.0pt;font-family:"Calibri",sans=
-serif;color:#1f497d"></span></p></div></div></blockquote></div></div></div=
></blockquote><div> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"><div><p class=
=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri&qu=
ot;,sans-serif;color:#1f497d"><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Gratuitous syntax is often unnecessar=
y and usually harmful. Saying<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"> &=
nbsp; template<class T, =
class U><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"> &=
nbsp; auto(T x, U y) -> =
decltype(x+y) { return x+y; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">does not appear to me to contain any =
more information than<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"> &=
nbsp; auto plus(auto x, aut=
o y) { return x+y; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">does it?</span></p></div></div></bloc=
kquote><div><br></div><div>To me, yes, it does. It says:</div><div><br></di=
v><div> * I deliberately want to allow the parameters to have differen=
t types</div></div></div></div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> *=
I deliberately want to allow the return type to differ from those types</d=
iv></div></div></div></blockquote><div><br></div><div>Does that mean that t=
he version using auto <i>accidentally</i> allows the arguments to have=
different types, and return a different type?</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div> * I want a substitution failure if x + y is not val=
id (your rewrite is possibly incorrect due to this)</div></div></div></div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div> * I want to "perfectly return" x=
+ y rather than always returning by value (your rewrite is possibly incorr=
ect due to this)</div></div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v> * It's OK for this apparent function definition to be in a header f=
ile despite not including the 'inline' keyword</div></div></div></div></blo=
ckquote><div><br></div><div>Does the use of <i>auto</i> as a parameter=
not also convey that? If it's treated consistently like a template functio=
n, I'd think it should.</div><div> </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> =
;* It's *not* OK to move this definition out of the header file.</div></div=
></div></div></blockquote><div><br></div><div>Use of <i>auto</i> as a =
return type implies that, since the definition must be in the TU.</div><div=
> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div> * And the big one: it says "this=
is a template". No need to go scanning the declaration for "auto" (or for =
concept names, not that you can identify them by sight). It's right there a=
t the start.</div><div><br></div><div>It's somewhat less clear to me how th=
is loss of readability balances against the possibility of improved readabi=
lity from a shorter declaration.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri&=
quot;,sans-serif;color:#1f497d">Requiring the verbose syntax is gratuitous,=
if the verbose syntax does not add information, does not serve to disambig=
uate anything, and does not highlight
a dangerous operation or anything else I can see that deserves to have att=
ention called to it.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">There=E2=80=99s a disturbing (to me a=
nd at least some others) trend in C++ these days: People seem to be very pr=
one to wanting =E2=80=9Cmore syntax=E2=80=9D lately. It=E2=80=99s rather Va=
sa-like,
if only lexically. Let me channel certain influential committee members an=
d say: =E2=80=98People these days are always asking for more syntax! There=
=E2=80=99s no proposal they=E2=80=99ve seen that they couldn=E2=80=99t make=
uglier with more syntax!=E2=80=99<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Important note: The point here is NOT=
terseness for terseness=E2=80=99 sake. I am not arguing that terser is som=
ehow better, that terseness is virtuous in itself. Too
many people glorify languages because they=E2=80=99re terser; fewer charac=
ters alone doesn=E2=80=99t make code clearer. Rather, my point is to avoid =
gratuitous verbosity. At the other end of the pendulum, too many people glo=
rify verbose syntax because they think _that_ is
somehow inherently clearer; usually it isn=E2=80=99t. So I am arguing that=
neither is verbosity virtuous in itself.</span></p></div></div></blockquot=
e><div><br></div><div>Right; we need to find a balance where the syntax we =
have is neither unnecessarily terse (to the point of causing readability an=
d maintenance problems) nor unnecessarily verbose. It is up to the people p=
roposing the change to demonstrate that this requirement is met, and the re=
actions on this thread seem to suggest that we are, so far, lacking a good =
argument that the proposed syntax meets the Goldilocks criterion.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"#0563=
C1" vlink=3D"#954F72"><div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d">Herb<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"=
;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:"Calibri",sans-serif"> Nicol Bolas [mailto:<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LWPz-Z9ZqEMJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, March 5, 2015 3:19 PM<br>
<b>To:</b> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"LWPz-Z9ZqEMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">std-dis..=
..@isocpp.org</a><br>
<b>Cc:</b> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"LWPz-Z9ZqEMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">std-pr...=
@isocpp.org</a>; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"LWPz-Z9ZqEMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">c++s=
t...@accu.org</a>; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"LWPz-Z9ZqEMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">fa=
i...@gmail.com</a><br>
<b>Subject:</b> [c++std-core-27204] Re: An implementation of enhanced auto =
deduction and abbreviated template syntax using Clang<u></u><u></u></span><=
/p>
</div>
</div><div><div>
<p class=3D"MsoNormal"><u></u> <u></u></p>
<div>
<p class=3D"MsoNormal">I... just... ugh.<br>
<br>
I'm fine with type deduction patterns like std::vector<auto> =3D ...;=
That's just a generalization of type deduction in static contexts.<br>
<br>
My issue is with, well, any syntax that declares a template without having =
to type either the word "template" or the use of "<>" brackets. Templ=
ates are a fundamentally different kind of construct, and we have specific =
syntax for doing so. By removing that
syntax, it becomes way too easy to not notice that you've declared a templ=
ate.<br>
<br>
The last thing we should want is for people to accidentally make something =
a template.<br>
<br>
I accept this with lambdas, because the main point of lambdas is that they'=
re a short-cut. Furthermore, they have a syntax that's fundamentally differ=
ent from regular functions. But for a regular function? No.<br>
<br>
Basically, if I see this:<br>
<br>
X func_name(...);<br>
<br>
I expect that &func_name ought to return a pointer. For it to do someth=
ing else, like being a compiler error, would be surprising.<u></u><u></u></=
p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - 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_93_1862912410.1425605455125--
------=_Part_92_927360727.1425605455125--
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Thu, 5 Mar 2015 23:01:46 -0600
Raw View
On Thu, Mar 5, 2015 at 7:01 PM, Richard Smith <richardsmith@google.com> wrote:
> On 5 March 2015 at 16:24, Herb Sutter <hsutter@microsoft.com> wrote:
>>
<snip>
* And the big one: it says "this is a template". No need to go scanning the
> declaration for "auto" (or for concept names, not that you can identify them
> by sight). It's right there at the start.
>
> It's somewhat less clear to me how this loss of readability balances against
> the possibility of improved readability from a shorter declaration.
>
+1.
How this fundamental syntactic tension shall resolve itself in time is
a futurity I wish I could claim authority on.
I confess, when *reading* code, I currently prefer to see the template
header to 'warn' me that a template is about to follow (just as i
usually prefer to *read* the type-name when variables are declared) -
but, given this thread, I wonder whether I should require that warning
- and whether it is simply an inertia that serves little useful
purpose. If I am allowed a touch of hyperbole, my worst fear is that
my use of abbreviated syntax shall be inconsistently driven by the
vagaries of an occasionally undisciplineable mood.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.