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

On Thu, Mar 5, 2015 at 3:23 AM, Jonathan Wakely <cxx@kayari.org> wrote:

> On 4 March 2015 at 17:59, Geoffrey Romer wrote:
> > Interesting; my reaction is precisely the opposite- I find enhanced auto
> > deduction very appealing (for reasons that others on this thread have
> > elaborated), but am actively uninterested in the abbreviated template
> > syntax. It seems to me to offer only a modest improvement in brevity, and
> > pays for it with a very substantial reduction in readability. That
> > compromise may be appropriate for lambdas, because brevity is
> particularly
> > important inside a single expression, but it seems far less justifiable
> in
> > the case of ordinary functions. Functions are not under the kinds of
> space
> > constraints that lambdas are, and function signatures (unlike lambda
> > signatures) often act as abstraction boundaries, so it's particularly
> > important for them to convey useful information to the reader.
>
> This conveys useful information:
>
> template<typename ForwardIterator>
>   ForwardIterator next(ForwardIterator);
>
> but that's still true if it's rewritten like this:
>
> ForwardIterator next(ForwardIterator);
>

That's not what I'm objecting to; I'm objecting to "auto" specifically. But
since you mention it, this version definitely conveys less information than
the previous one: it obscures the critical fact that 'next' is a function
template.


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


>
> 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. Even if a conceptified version of this
syntax is available, "auto" doesn't necessarily tell me that the operation
is generic; it may just mean that there's no named concept that captures
the meaning of the parameter.

--

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

--001a1147b5766a20a505108daa3d
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 3:23 AM, Jonathan Wakely <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 4 March 2015=
 at 17:59, Geoffrey Romer wrote:<br>
&gt; Interesting; my reaction is precisely the opposite- I find enhanced au=
to<br>
&gt; deduction very appealing (for reasons that others on this thread have<=
br>
&gt; elaborated), but am actively uninterested in the abbreviated template<=
br>
&gt; syntax. It seems to me to offer only a modest improvement in brevity, =
and<br>
&gt; pays for it with a very substantial reduction in readability. That<br>
&gt; compromise may be appropriate for lambdas, because brevity is particul=
arly<br>
&gt; important inside a single expression, but it seems far less justifiabl=
e in<br>
&gt; the case of ordinary functions. Functions are not under the kinds of s=
pace<br>
&gt; constraints that lambdas are, and function signatures (unlike lambda<b=
r>
&gt; signatures) often act as abstraction boundaries, so it&#39;s particula=
rly<br>
&gt; important for them to convey useful information to the reader.<br>
<br>
</span>This conveys useful information:<br>
<br>
template&lt;typename ForwardIterator&gt;<br>
=C2=A0 ForwardIterator next(ForwardIterator);<br>
<br>
but that&#39;s still true if it&#39;s rewritten like this:<br>
<br>
ForwardIterator next(ForwardIterator);<br></blockquote><div><br></div><div>=
That&#39;s not what I&#39;m objecting to; I&#39;m objecting to &quot;auto&q=
uot; specifically. But since you mention it, this version definitely convey=
s less information than the previous one: it obscures the critical fact tha=
t &#39;next&#39; is a function template.</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">
<br>
This doesn&#39;t convey any useful information:<br>
<br>
template&lt;typename T&gt;<br>
=C2=A0 void frob(T);<br></blockquote><div><br></div><div>I don&#39;t agree;=
 it tells me that frob is a generic operation that works with roughly any t=
ype T.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
so in terms of describing the interface it&#39;s no different when written<=
br>
like this:<br>
<br>
void frob(auto);<br></blockquote><div><br></div><div>This is different beca=
use now I don&#39;t know anything about the requirements or semantics of th=
e parameter type. Even if a conceptified version of this syntax is availabl=
e, &quot;auto&quot; doesn&#39;t necessarily tell me that the operation is g=
eneric; it may just mean that there&#39;s no named concept that captures th=
e meaning of the parameter.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Discussion&quot; 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 />

--001a1147b5766a20a505108daa3d--

.